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Preface 


The  data  base  group  at  the  University  of  Toronto  consists  of  four  faculty 
members  (Stavros  Christodoulakis,  Fred  Lochovsky,  Alberto  Mendeizon,  Dennis  Tsl- 
chritzis),  one  professional  programmer  (Alison  Lee),  and  1 6-20  graduate  students. 
We  are  presently  doing  research  in  many  areas  dealing  with  Data  Base  and  Office 
Information  Systems.  Our  work  is  a  interrelated  series  of  five  activities: 

(1)  We  evaluate  past  experiences,  think  about  new  problems,  and  question  our 
assumptions. 

(2)  We  abstract  system  capabilities  and  try  to  model  their  behavior. 

(3)  We  design  system  systems  from  the  beginning  and  try  out  novel  ideas. 

(4)  We  Implement  systems  In  a  prototype  environment  trying  various  new  tech¬ 
niques. 

(5)  We  analyze  the  systems  we  build,  make  them  available  to  the  world  for  testing 
and  comments  and  then  discard  them  to  go  into  a  new  cycle. 

This  report  is  a  collection  of  papers  on  Ideas  at  different  stages  of  develop¬ 
ment.  It  mainly  deals  with  Office  Information  Systems.  The  work  can  be  divided  into 
models  and  prototype  systems,  although  they  progress  together  influencing  each 
other.  We  mention  some  of  the  most  important  directions  that  we  are  following. 

1.  Models 

We  are  developing  a  model  to  represent  the  information  bearing  objects  found  In 
the  office  and  operations  upon  these  objects.  There  are  four  concepts  within  the 
model  -  object  types,  domains,  triggers  and  picture  types.  An  object  type  is  a  struc¬ 
tural  specification  of  the  properties  of  classes  of  objects.  These  specifications 
make  use  of  the  semantic  data  modelling  abstraction  mechanisms  of  aggregation  and 
specialization.  A  domain  describes  the  values  that  a  property  may  take.  Domains  are 
similar  to  abstract  data  types  In  that  their  internal  representation  Is  hidden  and  func¬ 
tions  are  defined  for  operating  upon  domains.  Triggers  are  used  for  specifying  con¬ 
straints  within  the  model.  A  procedural  rather  than  a  declarative  approach  has  been 
adopted  because  of  the  wide  variety  of  constraints  involving  object  types.  A  picture 
type  (e.g..  Icons,  templates,  and  tables)  is  a  graphic  image  used  for  displaying  Indivi¬ 
dual  objects  or  sets  of  objects. 

We  are  formulating  a  general  model  to  represent  Message  Management  Systems, 
A  Message  Management  System  is  a  framework  which  combines  aspects  from  Data 
Base  Management  Systems  and  Messac  3  Systems.  This  type  of  a  system  would  pro¬ 
vide  facilities  for  both  the  communication  and  management  of  Information.  The 
emphasis  is  on  formalizing  that  portion  of  the  model  that  deals  with  the  communication 
of  information.  It  is  this  aspect  that  separates  Message  Management  Systems  from 
Data  Base  Management  Systems.  In  a  Data  Base  Management  System,  the  Informa¬ 
tion  accessible  to  the  users  is  statically  defined  In  the  schema.  On  the  other  hand,  in 
a  Message  Management  System,  there  is  a  dynamic  evaluation  of  the  set  of  users 
that  have  access  to  a  piece  of  information  I.e.,  the  users  that  receive  the  information 
in  the  form  of  a  message.  This  set  of  users  can  change  as  a  message  Is  forwarded 
around  the  system.  The  different  schemes  for  addressing  messages  receive  special 
attention. 

As  an  Office  Information  System  changes  and  grows,  and  users  start  adding  new 
objects,  deadlocks,  infinite  loops,  dead  ends,  and  other  anomalies  may  occur.  The 
objects'  rules  may  Interact  in  unexpected  ways.  The  system  has  no  way  of  telling 
what  sort  of  behavior  Is  "suspicious”,  since  there  is  almost  no  a  priori  bad  behavior. 
We  are  trying  to  formalize  the  notions  of  "objects"  and  "rules"  for  the  purposes  of 


being  able  to  at  least  determine  what  sort  of  behaviour  can  be  expected.  Objects 
communicate  by  sending  one  another  messages.  An  object’s  rules  describe  how  that 
object  interacts  with  other  objects  (e.g.,  what  messages  may  be  received  from 
whom,  and  what  messages  may  consequently  be  forwarded).  From  this,  a  set  of  reg¬ 
ular  expressions  may  be  formed,  describing  the  possible  sequences  of  message  tran¬ 
sactions.  The  regular  expressions  may  also  be  used  to  describe  the  possible 
sequences  of  state  changes  that  the  objects  undergo.  In  the  event  that  the 
analysis  is  not  complete,  traps  for  bad  situations  are  set.  These  situations  may  or 
may  not  actually  arise,  but  still  appear  to  be  possible  as  far  as  the  analysis  is  con¬ 
cerned. 

We  are  studying  and  analyzing  the  performance  of  a  number  of  text  storage, 
access,  and  retrieval  schemes.  We  are  analyzing  the  integration  of  text  with  format¬ 
ted  data  in  the  same  environment.  The  access  methods  that  we  consider  have  some 
nice  properties: 

(1 )  they  are  appropriate  for  a  highly  changing  environment 

(2)  they  facilitate  complex  queries  Involving  text  and  data. 

(3)  the  access  mechanism  occupies  a  small  amount  of  storage. 

(4)  they  facilitate  retrieval  in  the  presence  of  "non-clean”  data  and 

(5)  they  are  appropriate  for  a  server  type  of  environment. 

2.  Prototype  Systems 

The  Office  Filing  System  is  a  prototype  system  that  supports  the  retrieval  of 
messages  containing  data  and  text  with  voice  and  image  annotations.  Messages 
such  as  letters  and  memos  are  filed  Into  a  general  file  (i.e.,  message  file).  The  filing 
facility  Is  augmented  with  a  search  capability  that  will  select  messages  based  on 
contents  and  retrieve  them  when  the  user  requests  it. 

The  user  gives  a  partial  specification  of  the  contents  of  the  message  that  he 
wants  to  see.  The  partial  specification  is  the  conjunction  of  the  selection  criteria  on 
the  various  components  of  the  message.  These  criteria  may  include  the 
values/patterns  present  In  the  attribute  and  text  fields  of  the  desired  message.  The 
selection  may  also  be  guided  by  the  specification  of  the  presence  or  absence  of 
Images  In  certain  locations  of  the  message  and  voice  annotations.  The  selection 
specification  acts  as  a  filter  that  restricts  the  attention  of  the  messages  in  the  mes¬ 
sage  file  to  a  manageable  subset. 

The  system  assists  the  user  in  isolating  the  desired  messages  from  this  subset. 
Miniatures  for  the  messages  along  with  their  "fast  talk"  (speed  up  voice  annotations) 
are  played.  The  miniatures  can  be  expanded  to  allow  the  user  to  view  the  full  mes¬ 
sage  in  more  detail.  The  user  may  then  read  the  contents  of  the  full  message  or 
listen  to  the  voice  annotations.  The  "fast  talk"  and  the  miniatures  enable  the  user  to 
play  fast  many  filtered  messages  and  Isolate  as  quickly  as  possible  the  messages  he 
is  Interested. 

The  Intelligent  Mail  System  (Imail  for  short)  unlike  a  regular  mail  system,  has 
messages  with  local  intelligence.  Each  message  has  control  over  what  it  lets  the 
recipient  sees,  what  It  asks  the  recipient,  how  it  processes  the  answers  received 
from  recipients,  how  It  determines  its  own  routing,  and  how  it  effects  its  own  termina¬ 
tion.  Such  an  intelligent  mall  system  is  currently  being  implemented  with  centralized 
control. 

In  Its  current  form,  Imall  runs  as  a  post  office.  The  sender  creates  the  intelligent 
message  (imessage  for  short)  In  a  manner  similar  to  a  programmer  writing  a  program. 
An  imessage  consists  of  four  pieces  of  information  -  the  type  of  and  initial  contents 
of  the  shipping  list,  actions  executed  when  recipient  receives  the  imessage,  the 
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routing  scheme,  and  termination  conditions  and  cleanup  actions.  The  imessage  along 
with  the  data  collected  thus  far  and  the  current  status  of  the  Imessage  are  kept  In 
the  post  office.  It  should  be  possible  to  'grab*  the  Imessage  to  hold  or  terminate  the 
imessage  from  running  around  the  system. 

Once  mailed,  the  imessage  deposits  itself  at  one  or  more  recipients'  mail  box  in 
the  post  office,  depending  on  the  form  of  the  shipping  list  awaiting  execution.  The 
imessage  allows  the  recipient  to  add  new  recipients  to  the  shipping  list.  On  comple¬ 
tion,  the  imessage  ships  itself  to  the  next  recipient.  If  the  recipient  does  not  reply 
to  the  Imessage  (i.e.,  run  it),  the  Imessage  can  timeout.  In  such  a  case,  the  imessage 
would  either  hold  off  on  this  recipient  until  a  later  time  or  pass  over  this  recipient.  In 
the  case  when  the  user  does  not  want  to  bother  with  the  imessage,  the  imessage 
moves  on  to  the  next  recipient.  On  completion  of  its  task,  the  Imessage  cleans  up 
after  Itself  and  sends  any  results  obtained  to  the  sender. 

The  Object  Oriented  Programming  System  is  an  implementation  of  an  object 
oriented  environment  which  can  be  used  for  putting  together  event  driven  Office 
Information  Systems.  Message  management  systems  and  office  information  systems 
provide  facilities  for  automatically  triggering  procedures  when  certain  conditions 
become  true  or  particular  events  take  place  such  as  receipt  of  mail.  Such  systems 
are  characterized  by  a  high  degree  of  parallel  activity  that  cooperates  with  but  may 
run  independently  of  user  processes.  Traditional  high-level  programming  languages 
do  not  readily  capture  this  sort  of  behaviour.  This  makes  building  a  customized  MMS 
or  OIS  a  painful  process. 

We  believe  that  '’objects”  are  a  useful  primitive  for  designing  and  building  such 
systems  quickly.  Objects  are  "black  boxes"  with  contents  and  behaviour.  A 
behaviour  is  a  set  of  rules  describing  how  objects  communicate  and  change  state. 
An  Object  Oriented  Programming  System  manages  the  contents  of  object  Instances 
and  searches  for  "events"  involving  several  objects  with  matching  rules.  When  an 
event  is  found  by  the  system.  It  Is  fired,  and  the  participants  of  the  event  may 
change  state.  The  Object  Oriented  Programming  System  project  is  being  Implemented 
in  terms  of  user  interface  and  the  object  manager  which  coordinates  the  events  and 
the  object  interaction. 

We  are  experimenting  with  many  ideas  for  user  interfaces  dealing  with  many 
issues  in  Data  Base  and  Office  Information  Systems.  We  are  looking  Into  the  design 
of  a  hardware  processor  to  support  a  message  retrieval  system.  The  current  work 
concentrates  on  textual  data  and  investigating  the  functional  requirements  and 
query  languages  of  a  message  retrieval  system,  and  the  various  components  of  a 
message  retrieval  machine. 

Finally,  it  is  customary  in  our  reports  to  give  a  glimpse  of  us  as  human  beings 
instead  of  straight  dry  computer  technicians.  In  this  report,  we  present  our  contribu¬ 
tion  to  archeology.  It  took  Professor  Meritt  and  his  colleagues  60  years  to  accumu¬ 
late  the  source  data  for  the  Athenians.  This  fact  should  give  us  some  perspective 
about  our  own  short  time  frames  and  lack  of  academic  discipline.  Hopefully,  we  can 
also  learn  to  stay  on  course  for  such  a  long  time  attacking  a  significant  problem. 


D.  Tsichritzis 
June  1  983 
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ABSTRACT 


There  is  a  perception  these  days  that  office  workers  are  not  as  productive  as 
they  should  be.  Whether  or  not  this  is  the  case,  the  emerging  office  technology 
provides  great  potential  to  improve  office  productivity  by  introducing 
specific,  computerized  support  tools  to  aid  office  workers.  In  this  paper  we 
look  at  ways  in  which  office  workers  can  be  better  supported  by  providing 
computer-based  tools  that  allow  them  to  more  easily  access  and  process 
computerized  data,  to  better  understand  their  work  environment  and  help 
computerize  it,  and  to  assist  them  in  managing  their  time  and  performing  their 
office  tasks  more  effectively.  Our  view  is  that  the  greatest  productivity  gains 
will  be  realized  by  better  supporting  office  workers,  rather  than  trying  to 
displace  them. 


Abstract 


ii 


1.0  INTRODUCTION 


The  ubiquitous  microprocessor  is  rapidly  invading  the  office  workplace.  One 
sees  it  everywhere — in  typewriters,  in  telephones,  in  copying  machines ,  even  in 
some  office  coffee  machines!  Its  presence  allows  some  "intelligence”  to  be  put 
into  office  tools,  thereby  "automating"  many  of  the  mundane  and  repetitive  tasks 
in  the  office.  But  where  is  it  all  leading  and  what  does  it  mean  for  the  office 
worker  of  the  future,  if  indeed  there  will  be  an  office  worker  in  the  future  as 
we  know  him  or  her  today? 

To  answer  these  questions,  we  need  to  e.xamine  at  least  two  aspects  of  "office 
automation."  First,  we  need  to  look  at  where  the  technology  is  or  may  be  leading 
us.  This  will  allow  us  to  get  some  idea  of  what  the  office  of  the  future  may 
look  like.  Second,  we  need  to  look  at  the  motivation  for  introducing  this 
technology  into  the  office.  This  will  allow  us  to  perhaps  see  what  people  will 
be  doing  in  those  offices.  By  knowing  what  future  offices  may  look  like  and  what 
kinds  of  activities  will  be  taking  place  in  those  offices,  we  can  identify  areas 
in  which  office  systems  can  help  increase  office  productivity. 


1.1  OFFICE  TECHNOLOGY 


In  1980,  approximately  $120  billion  was  spent  on  office  systems  (i.e.,  tools  and 
materials  that  support  office  workers).  Approximately  $90  billion  of  this  was 
spent  on  hardware  and  services,  the  rest  being  staff  expenses  to  support  the 
hardware  and  services.  Spending  on  office  systems  is  expected  to  grow  at  the 
rate  of  at  least  5%  annually  to  1990  [Panko,  1982].  At  the  same  time,  according 
to  one  prediction,  the  cost  of  hardware,  which  has  dropped  dramatically  in  the 
last  decade,  is  expected  to  continue  to  drop  at  30%  to  40?^  annually  in  the  1980s 
[Traub,  1981] . 

On  the  other  hand,  people  costs,  in  terms  of  salary,  have  risen  dramatically  and 
are  expected  to  continue  to  rise  in  the  1980s.  What  this  means  is  that  the 
payout  ratio,  that  is  the  ratio  of  cost  of  technology  versus  the  cost  of  people, 
is  dropping.  Whereas  the  payout  ratio  in  1970  for  a  fixed  amount  of  processing 
power  was  4800^,  and  in  1980  it  was  210,  in  1990  it  is  expected  to  be  in  the  2  to 
8  range  [Benjamin,  1982].  The  decision  to  buy  a  computer  or  hire  a  person  thus 
almost  becomes  a  one  to  one  trade-off  and  the  cost  justification  for  the 
technology  becomes  much  easier  than  in  the  past. 

Because  of  the  continued  expected  improvements  in  the  cost  of  computer 
technology,  the  cost  of  today's  terminal  will  buy  a  powerful  workstation  in 
1990.  Such  a  workstation  will  contain  a  32  bit  microprocessor  and  have 
computing  power  approaching  that  of  an  IBM  4341.  The  cost  of  such  a  workstation 
will  be  approximately  11?^  of  a  clerical  person's  or  4%  of  a  professional 
person's  salary  in  1990.  This  approaches  the  cost  of  a  telephone  today  with 


That  is,  one  could  pay  the  salary  of  4800  clerical  workers  for  one  year  for 
the  purchase  price  of  a  fixed  amount  of  computer  processing. 
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respect  to  salary!  Thus,  the  workstation  will  be  ubiquitous  in  the  office  in 
1990  and  multi-functional  [Benjamin,  1982] . 

The  preceding  hardware  scenario  has  several  implications  for  how  th(’  technology 
will  be  used  in  the  office  and  where  it  will  be  placed.  Whereas  in  the  70s  and 
early  80s  operational  areas  dominated  use  of  computer  cycles,  end  users  (i.e., 
office  workers)  will  dominate  the  use  of  computer  cycles  by  1990.  While 
centralized  systems  will  still  exist  to  meet  operational  requirements,  the  shift 
to  end  user  computing  means  that  much  of  the  data  and  computing  power  will  be 
distributed  to  the  lowest  levels  of  the  organization,  if  this  makes  operational 
sense .  ^ 

In  terms  of  software,  the  growing  cost  of  people  means  that  expensive 
application  specialists  will  have  to  be  used  sparingly.  Thus  local  operations 
must  be  turn-key  in  order  to  reduce  the  need  for  such  specialists.  Data  base 
access  will  be  mainly  on-line  so  that  end  users  can  directly  access  their  data. 
Software  systems  will  need  to  be  better  human  engineered  to  maintain  their 
effectiveness  for  the  organization. 


1.2  OFFICE  PRODUCTIVITY 


Office  work  is  very  labor  intensive.  The  cost  of  this  labor  is  increasing  at  a 
rate  of  5%  to  10%  a  year  and  is  expected  to  continue  to  do  so  in  the  1980s. 
Productivity  of  office  workers,  on  the  other  hand,  is  improving  at  a  rate  of 
between  0.4%  and  1.3%  per  year  depending  on  how  one  calculates  it  [Byron,  1980; 
Panko,  1982] .  It  is  generally  felt  that  offices  are  not  as  productive  as  they 
could  be  (or  should  be)  given  the  rising  costs  of  office  work.  Since  technology 
costs  are  falling  and  people  costs  are  rising,  it  is  reasoned  that  rather  than 
hire  more  people  it  makes  good  economic  sense  to  purchase  more  technology.  In 
this  way,  one  can  avoid  increasing  the  work  force  by  providing  the  existing  work 
force  with  tools  that  will  relieve  them  of  many  of  their  more  repetitive  tasks 
and  assist  them  in  the  performance  of  their  other  tasks.  Thus,  the  existing 
office  worker  will  become  more  productive. 

Given  that  office  productivity  needs  to  be  improved  and  that  technology  can 
bring  about  the  improvements,  the  question  arises  "Where  is  the  productivity 
gain  in  the  office  of  the  future  to  be  realized?"  To  answer  this  question,  it  is 
first  necessary  to  determine  what  we  mean  by  productivity  in  the  office. 

One  definition  of  productive,  and  the  one  that  we  will  use  here,  is  "producing 
or  tending  to  produce  goods  and  services  having  exchange  value"  [Random  House, 
1980] .  The  important  aspect  of  this  definition  is  that  the  goods  or  services 
have  an  exchange  value.  The  productivity  of  an  endeavor  is  then  a  matter  of 
maximizing  the  exchange  value  of  the  goods  and  services  produced. 


Under  the  assumption  that  processing  power  is  equivalently  cheap  no  matter 
where  it  is  placed  and  that  communication  costs  will  always  favor 
distribution. 
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Under  this  definition,  there  are  two  ways  in  which  productivity  can  be  improved: 
either  by  increasing  the  quantity  or  by  increasing  the  quality  of  the  goods 
produced  and  ther~eby  increasing  their  exchange  value.  In  any  production 
situation,  there  is  thus  always  a  trade-off  between  quantity  and  quality  of 
goods  and  services  produced. 

In  an  industrial  environment,  the  quality  of  the  goods  produced  is  usually 
tightly  controlled  by  the  nature  of  the  production  facility.  This  is  possible 
since  the  goods  produced  can  be  standardized  by  employing  standard  inputs  and 
standard  means  of  production.  In  addition,  the  production  of  the  goods  does  not 
involve  a  great  deal  of  decision  criteria  on  how  they  should  be  produced;  every 
step  is  usually  predetermined.  Quality  assurance  is  then  a  matter  of  making 
certain  that  the  steps  are  carried  out  properly  and  according  to  certain 
standards.  Productivity,  in  this  scenario,  is  only  a  matter  of  measuring  the 
quantity  of  the  goods  produced,  their  quality  being  given. 

In  the  office  environment,  the  means  of  production  are  not  as  tightly  controlled 
as  in  the  industrial  environment.  People  have  a  great  deal  more  discretion 
about  how  the  final  product — information — will  be  produced.  Inputs  are  not 
always  all  standardized  or  of  uniform  quality.  Many  exceptional  situations  and 
conditions  arise  that  need  to  be  dealt  with.  Productivity  is  not  merely  a 
matter  of  measuring  quantity  of  information  produced,  but  also  its  quality. 

Given  this  situation,  how  can  office  productivity  be  improved?  One  approach 
that  can  be  taken  is  to  standardize  the  work  environment  as  in  the  industrial 
case.  This  would  mean  controlling  the  quality  of  the  work  and  streamlining  the 
means  of  production  so  that  more  could  be  produced  per  unit  time. 
Unfortunately,  this  approach  to  office  automation  is  often  the  one  followed  in 
organizations  and  has  resulted  in  strong  opposition  to  automation  in  the  office 
[Gregory  and  Nussbaum,  1982].  In  such  a  situation,  microprocessors  are  viewed 
as  *' job-ki  1  lers”  and  the  jobs  that  remain  become  deskilled  as  the  work 
environment  becomes  more  and  more  standardized. 


1.3  OFFICE  SUPPORT 


An  office  is  not  a  single,  homogenous  entity,  but  rather  different  types  of 
offices  can  be  identified  [Panko  and  Sprague,  1982].  Some  of  these  offices  deal 
with  high  volumes  of  transactions  of  usually  standardized  inputs  and  processing 
procedures.  Others  deal  with  policy  and  professional  functions  in  which  the 
focus  is  on  selecting  and  meeting  goals.  Most  offices  contain  a  mixture  of  both 
types  of  information  processing. 

In  such  a  situation,  an  alternative  approach  that  can  be  taken  to  office 
automation  recognizes  that,  although  information  is  a  product,  it  is  not  always 
possible  nor  desirable  to  standardize  it  or  its  production.  Instead  of  being 
standardized,  the  means  of  production  are  diversified  by  taking  advantage  of  the 
adaptability  of  the  machine  (computer),  rather  than  the  person.  Office  workers 
are  supplied  with  tools  that  help  automate  the  former  types  of  processing  and 
help  support  the  latter  types  of  processing.  Office  work  thus  becomes  more 
diversified  and  th(  jobs  become  enriched  rather  than  deskilled. 
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Because  of  the  current  backlog  of  application  development  and  the  future 
anticipated  demand  for  application  development,  it  is  unlikely  that  automation 
win  occur  very  rapidly  in  the  office.  Rather,  productivity  improvements  in  the 
office  are  likely  to  stem  from  specific  tools  that  support  office  work  rather 
than  general  tools  that  automate  the  office  [Panko  and  Sprague,  1982] . 
Eventually  these  tools  may  evolve  to  a  stage  where  it  is  possible  for  the  office 
worker  himself  to  "program"  the  office  system  to  automate  some  of  his  tasks. 
This  would  certainly  speed  up  application  development  in  the  office  and  enrich 
the  jobs  of  office  workers. 

In  this  paper  we  look  at  specific  areas  in  which  support  for  office  work  can  be 
provided.  The  emphasis  is  to  highlight  those  areas  where  appropriate  tools  can 
help  support  office  work.  We  identify  research  which  is  being  done  on 
computer-based  tools  that  can  potentially  help  support  office  workers  rather 
than  displace  them.  Our  view  is  that,  in  the  long  run,  this  is  where  the 
greatest  productivity  gains  in  the  office  will  be  realized. 
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2.0  END  USER  FACILITIES 


If  office  workers  are  to  be  more  productive  in  processing  information,  much 
better  and  more  integrated  end  user  facilities  than  are  available  now,  in  terms 
of  entering,  querying  and  storing  data  will  have  to  be  provided.  The  way  in 
which  data  processing  systems  have  been  designed  in  the  past  has  not  really 
considered  or  made  use  of  the  interactive  nature  of  the  computer  environment. 
The  facilities  provided  by  many  data  base  management  systems  (DBMSs)  are  much 
more  suited  to  a  batch  processing,  application  development  environment,  than  an 
end  user,  interactive  environment.  In  addition,  the  capabilities  of  the  current 
technology,  especially  in  terms  of  the  variety  of  input  and  output  devices  now 
available,  have  not  been  fully  utilized. 

The  human  engineering  of  office  systems  will  play  a  crucial  role  in  improving 
the  productivity  of  the  office  worker  (Thomas,  1982].  Making  computer  systems 
"user  friendly"  usually  consumes  a  considerable  amount  of  computer  resources. 
While  there  are  trade-offs  between  cost  and  human  factors,  these  trade-offs  have 
changed  considerably  in  the  last  twenty  years.  When  computer  cycles  were  a 
scarce  resource,  there  were  arguments  to  be  made  for  excluding  user  oriented 
features.  Now,  however,  computer  cycles  are  much  less  expensive  and  more 
abundant.  It  is  now  feasible  and  imperative  to  use  more  of  these  cycles  to 
improve  the  human  factors  aspects  of  computer  software. 


2.1  DIRECT  MANIPULATION 


In  the  office  of  the  future,  most  data  will  be  stored  electronically  in  data 
bases.  The  way  in  which  data  in  a  data  base  is  currently  stored  and  accessed 
requires  an  application  specialist  to  act  as  an  intermediary  between  the  user 
and  the  data.  This  is  because  the  types  of  models  of  data  organization  used  and 
the  way  in  which  the  data  are  accessed  require  some  degree  of  specialized 
knowledge  and  programming  skill  [Tsichritzis  and  Lochovsky,  1982].  If  office 
productivity  is  to  improve,  office  workers  will  have  to  be  provided  with 
facilities  to  directly  access  this  data. 

To  meet  this  objective,  the  end  user  facilities  in  the  office  of  the  future  will 
move  away  from  employing  syntax  and  commands  for  manipulating  data  to  what  has 
been  termed  "direct  manipulation"  [ Shneiderman ,  1982].  Direct  manipulation 
involves  physical  actions  rather  than  syntactic  constructs  for  carrying  out 
various  operations.  Objects  that  are  to  be  manipulated  are  represented  directly 
on  the  display  screen.  Physical  action  on  these  objects  replaces  the 
specification  of  what  is  to  be  done.  The  idea  is  to  perform  actions  by  doing 
rather  than  by  tell ing . 

Several  DBMSs  already  employ  or  have  moved  toward  this  paradigm  for  manipulating 
data.  In  the  QBE/OBE  system,  the  data  objects  consist  of  templates  for 
relations  or  forms  [Zloof,  1977  ,  1981].  The  user  manipulates  the  data  in  the 
data  base  directly  through  these  templates  and  forms.  Thus  the  paradigm  for 
manipulating  the  d.ita  objects  corresponds  very  closely  to  the  way  in  which  the 
physical  objects  would  be  manipulated.  Similar  ideas  are  used  in  SBA  [Zloof  and 


2.0  END  USER  FACILITIES 


5 


De  Jong,  1977;  De  Jong,  1980],  OFS/TLA  [Tsichritzis ,  1982;  Tsichritzis,  et  al., 
1982],  Xerox  Star  [Purvy  et  al.,  1982],  Apple  Lisa  [Williams,  1983],  and 
VisiCorp's  VisiOn  [Folk,  1983].  There  are  also  proposals  that  would  allow  a 
user  to  browse  through  a  data  base  much  like  one  can  now  browse  through  a  text 
document  electronically  [Mendelzon,  1982;  Stonebraker  and  Kalash,  1982].  The 
paradigm  used  here  is  that  of  a  text  editor  and  operations  are  similar  to  those 
for  editing  text. 

In  addition  to  representing  data  objects  directly  on  the  screen  for 
manipulation,  one  can  also  represent  system  utilities  on  the  screen.  These 
representations  are  usually  in  terms  of  icons  that  present  a  pictorial 
representation  of  the  facility.  For  example,  a  filing  cabinet  can  be 
represented  as  a  drawing  of  a  filing  cabinet.  The  filing  operation  can  then  be 
defined  as  the  action  of  physically  moving  a  data  object,  such  as  a  form,  to  the 
filing  cabinet  icon.  This  paradigm  is  used  in  the  Xerox  Star  system  [Smith  et 
al.,  1982;  Purvy  et  al.,  1982],  Apple  Lisa  system  [W-illiams,  1983],  and  in  the 
prototype  message  management  system  under  development  at  the  University  of 
Toronto  [Lee,  1983;  Woo,  1983]. 


2.2  INTEGRATED  DATA  BASES 


Office  data  consists  of  many  diverse  types  of  data — letters,  reports,  memos, 
forms,  graphs,  charts,  pictures,  telephone  calls,  etc.  A  limitation  of  many 
data  processing  systems  has  been  their  inability  to  handle  anything  except 
highly  structured  data.  Even  when  different  types  of  data  could  be  handled,  the 
user  interface  to  these  different  types  of  data  were  often  quite  specific  to  the 
type  of  data.  All  of  these  types  of  data  need  to  be  stored  and  manipulated  in  an 
integrated  manner  if  office  systems  are  to  be  useful  in  supporting  office  work. 
Switching  modes  of  interaction  to  handle  different  types  of  data  interrupts  the 
work  flow  resulting  in  lower  productivity. 

Since  all  of  these  diverse  data  need  to  be  managed,  it  seems  natural  to  provide 
the  integrating  capability  via  a  DBMS.  The  move  towards  integration  has  already 
begun.  Several  DBMSs  have  integrated  or  are  integrating  text  and  structured 
data  [Stonebraker  et  al.,  1982;  Tsichritzis  and  Chr istodoulakis ,  1983].  DBMSs 
have  been  used  to  manage  image  data  [Chang  and  Fu,  1980;  Fu  and  Chang,  1981]  and 
systems  that  integrate  the  management  of  image  and  structured  data  are  being 
developed  [Economopoulos  and  Lochovsky,  1983].  Systems  that  integrate  text  and 
voice  data  are  also  being  developed  [Maxemchuk,  1980;  Maxemchuk  and  Wilder, 
1980] . 

The  challenge  in  these  efforts  is  not  only  to  provide  the  individual 
capabilities  for  handling  the  diverse  types  of  data,  but  for  handling  them  in  a 
uniform  way  in  the  user  interface.  Even  if  all  the  different  types  of  data  are 
provided  within  one  system,  it  would  still  be  very  frustrating  to  use  such  a 
system  if  different  user  interfaces  (i.e.,  commands  and  interaction  protocols) 
are  required  for  each  type  of  data  stored.  The  challenge  then  is  to  find  a 
paradigm  of  data  manipulation  that  is  common  to  most  types  of  data. 

One  approach  that  is  being  followed  is  that  of  defining  a  virtual  editor 
[Maxemchuk  and  Wilder,  1981].  A  virtual  editor  is  an  abstraction  of  a  real 
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editor  that  defines  editing  operations  that  are  common  to  many  types  of  data. 
This  notion  has  already  been  applied  to  the  editing  of  text  and  speech  using  a 
common  paradigm  [Wilder  and  Maxemchuk,  1982]  .  In  this  way,  the  user  has  a 
common  framework  within  which  he  can  access  and  manipulate  many  different  types 
of  data.  There  is  no  need  to  learn  a  different  ’’language”  for  each  type  of  data. 


2.3  NATURAL  LANGUAGE 


Access  to  a  data  base  usually  requires  a  combination  of  syntactic  and  semantic 
knowledge  [Turner  et  al.,  1982).  That  is,  a  person  must  know  how  to  access  the 
data,  usually  via  an  artificial  language,  and  they  must  know  what  data  there  is 
to  access.  Most  people  have  a  very  good  idea  of  what  data  there  is  in  their 
application  domain,  but  not  its  exact  computer  (i.e.,  data  base)  representation. 
In  addition,  they  have  acquired,  through  education,  a  syntactic  way  of  posing 
queries,  namely  natural  language.  However,  since  most  DBMSs  use  artificial  data 
structures  and  languages  for  organizing  and  accessing  a  data  base,  there  is  a 
mismatch  between  a  user’s  conceptualization  of  the  data  and  how  the  data  is 
actually  structured  and  queried  [Harris,  1977). 

To  correct  this  situation,  it  seems  natural  therefore  to  allow  users  to  pose 
their  queries,  not  in  an  artificial  language,  but  in  their  native  language  (in 
our  case  English).  The  problem  with  this  approach  is  that  it  is  well  known  that 
English  is  an  ambiguous  and  imprecise  language.  In  addition,  the  interpretation 
of  many  English  language  statements  depends  on  the  context  they  are  in  and 
possibly  on  some  assumed  knowledge  about  the  domain  of  discourse.  Thus,  in 
general,  precisely  interpreting  an  arbitrary  English  language  sentence  is  an 
extremely  difficult  problem. 

However,  by  using  restricted  forms  of  English  and  by  limiting  the  domain  of 
discourse  to  a  specific  application  area,  it  is  possible  to  construct  natural 
language  querying  systems  that  have  reasonable  performance  [Harris,  1977; 
Hendrix  et  al.,  1978].  By  restricting  the  domain  of  discourse  to  a  specific 
application,  it  is  possible  to  predict  the  user’s  linguistic  behavior.  Thus, 
only,  a  narrow  subset  of  the  natural  language  actually  needs  to  be  covered.  In 
addition,  it  has  been  found  that  users  adapt  fairly  quickly  to  what  the  system 
will  accept  [Harris,  1977;  Hendrix  et  al.,  1978].  By  providing  extension 
capabilities,  such  as  synonyms  and  paraphrases,  the  user  is  able  to  enlarge  the 
domain  of  discourse  and  in  some  sense  tailor  the  system  to  suit  his  style  of 
expression  [Hendrix  et  al.,  1978].  This  approach  appears  to  have  great  promise 
for  improving  the  productivity  of  people  in  the  office.  They  will  not  have  to 
learn  a  special  language  for  interacting  with  the  computer  system  or  employ 
application  programmers  to  make  use  of  ohe  data  in  the  data  base. 


2.4  SPEECH 


The  most  natural  way  for  people  to  communicate  is  by  speech.  This  is 
particularly  important  in  the  office  where  many  of  our  existing  tools  (e.g.. 
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telephones,  meetings)  are  oriented  towards  use  of  speech  for  communication. 
Speech  is  also  a  faster  communication  medium  than  reading  or  writing  and  thus 
has  obvious  uses  for  improving  office  productivity.  As  the  use  of  speech  in  the 
office  has  not  changed  for  a  long  time,  the  office  of  the  future  will  have  to 
support  speech  communication  in  some  form  [White,  1981]. 

Speech  communication  can  be  divided  into  two  distinct  aspects:  speech  output 
(i.e.,  talking)  and  speech  input  (i.e.,  listening).  In  addition,  the  output 
part  has  two  uses.  First,  it  can  be  used  merely  to  convey  a  message  (i.e.  ,  it  is 
only  a  medium  for  transmission,  like  paper).  On  the  other  hand,  it  can  be  used 
to  generate  instructions  that  are  used  to  control  some  other  processing.  Each 
of  these  are  distinct  uses  of  speech  in  the  office  and  each  has  its  own 
difficulties  in  terms  of  computerization. 

The  use  of  speech  as  merely  a  transmission  medium  is  perhaps  the  easiest  to 
provide.  In  this  case,  it  is  only  necessary  to  be  able  to  record  and  play  back 
the  speech  message.  No  understanding  of  the  contents  of  the  message,  by  the 
computer,  is  necessary.  Some  prototype  and  commercial  systems  that  support 
speech  messages  have  been  implemented  [Graham  and  Lerner,  1982;  Richards,  1981]. 
The  major  advantage  of  such  systems  is  the  ability  to  leave  messages  when  the 
receiving  party  is  not  available  and  the  ability  to  play  back  messages  at 
leisure.  In  addition,  once  the  messages  have  been  computerized,  there  is  the 
possibility  of  processing  them  subsequently  (e.g.,  to  translate  them  to  text). 
This  recording  technique  can  also  be  used  to  voice-annotate  existing 
computerized  documents. 

The  use  of  speech  for  output  (other  than  messaging)  is  a  slightly  more  difficult 
problem.  Here  the  idea  is  to  be  able  to  speak  an  arbitrary  text  in  some  spoken 
language.  For  example,  one  might  want  to  hear  written  instructions  or  verify 
the  entry  of  data.  This  requires  the  ability  both  to  translate  written  words  to 
spoken  form  and  to  synthesize  speech  [Lee,  1982;  Lee  and  Lochovsky,  1983].  Such 
systems  have  obvious  uses  for  handicapped  people.  In  addition,  they  can  improve 
productivity  for  office  workers  by  allowing  them  to  be  more  mobile  while  still 
assimilating  information  since  speech  is  omni-directional. 

The  final,  and  most  difficult,  area  for  using  speech  in  the  office  is  that  of 
speech  recognition  (i.e.,  the  ability  to  understand  what  is  being  spoken).  This 
understanding  can  take  two  forms:  discrete  recognition  and  continuous 
recognition.  The  former  holds  some  promise  for  improving  office  productivity  by 
allowing  instructions  to  the  computer  to  be  spoken  rather  than  typed.  The 
latter  could  be  used  for  such  things  as  a  voice  driven  typewriter.  However,  the 
state  of  the  art  in  continuous  speech  recognition  is  not  yet  at  a  stage  where 
this  is  feasible  for  unrestricted  speech.  For  example,  it  is  very  hard  for  a 
computer  to  know  the  difference  between  homonyms  unless  it  also  has  some 
semantic  knowledge  such  as  sentence  structure.  Some  prototype  speech 
recognition  systems  have  achieved  an  80?o  to  90/o  recognition  rate  with  a 
restricted  vocabulary  [Erman  et  al.,  1980].  Currently,  however,  they  require  a 
great  deal  of  processing  power  to  perform  the  speech  recognition  (e.g.,  an  IBM 
370  or  DEC  10) . 
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3.0  APPLICATION  DEVELOPMENT 


If  the  technology  scenario  described  in  Section  1  comes  to  pass,  computing  power 
will  not  be  a  problem  in  the  office.  However,  harnessing  this  power  for  useful 
work  may  be  a  major  obstacle  to  improving  office  productivity.  Already  in  many 
organizations  trying  to  deal  with  the  demand  for  computer  applications  is  a 
major  problem.  If  we  add  to  the  already  existing  backlog  of  applications  the 
ones  for  the  office,  our  ability  to  deal  with  them  effectively  may  be  a  major 
constraining  factor  on  the  introduction  of  office  systems  [Benjamin,  1982; 
MacDonald,  1982]. 

Software  development  is  the  dominant  cost  in  computer  systems  today  [Wasserman 
and  Gutz,  1982).  It  can  represent  up  to  80%  of  the  system  development  cost. 
Skilled  application  programmers  are  in  short  supply  and  are  expected  to  cost  in 
excess  of  $100,000  per  year  (including  salary,  benefits  and  overhead)  by  the  mid 
1990s  [Wasserman  and  Gutz,  1982].  Software  development  costs  need  to  be 
controlled  if  office  software  is  to  be  developed  at  reasonable  cost.  In 
addition,  the  quality  of  the  software  being  developed  also  needs  to  be  improved. 


3.1  OFFICE  MODELLING 


Before  we  can  automate  the  office,  we  need  to  be  able  to  understand  what  goes  on 
in  an  office.  Thus  we  need  to  develop  and  use  models  that  allow  us  to  capture 
the  data,  processing  and  communication  requirements  in  an  office.  These  models 
will  improve  office  productivity  by  allowing  easier  development  and  maintenance 
of  office  applications.  Once  an  office  application  is  specified  by  a  precise 
model,  it  is  much  more  amenable  to  computerization.  A  second  way  in  which 
office  models  can  improve  office  productivity  is  by  permitting  the  analysis  of 
existing  work  flow  within  an  office.  By  capturing  this  information  in  an 
appropriate  office  model,  it  may  be  possible  to  improve  the  work  flow  by 
restructuring  it. 

Many  different  types  of  office  models  have  been  developed  in  the  last  few  years 
that  try  to  capture  information  requirement  aspects  of  an  office.  In  terms  of 
office  data  and  procedures,  these  models  are  basically  of  two  types:  those  that 
emphasize  data  semantic  aspects  and  those  that  emphasize  communication  aspects. 
In  the  data  semantic  approach  to  office  modelling,  one  tries  to  capture  the 
different  types  of  data  objects  that  exist  in  an  office  and  the  operations  on 
those  objects  [Gibbs,  1982].  In  the  communication  approach,  one  tries  to  model 
how  the  data  objects  are  transmitted  among  the  various  workstations  in  the 
office  and  what  processing  each  workstation  does  on  the  data  objects  [DeJong, 
1980;  Ellis  and  Nutt,  1980;  Martin  and  Tsichritzis,  1982].  There  are  also 
modelling  approaches  that  follow  more  traditional  data  processing  techniques 
for  modelling  offices  (e.g.,  input-processing-output  models)  [Lebensold  et  al., 
1982] . 

An  office  is  not  a  static  environment;  the  types  of  data  that  are  processed  and 
the  manner  in  which  they  are  processed  change  over  time.  In  the  past,  due  to 
their  nature,  offices  have  not  usually  been  reorganized  very  often.  Such  an 
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occurrence  is  very  disruptive  and  difficult  to  carry  out  in  a  manual  office. 
Business  forms  may  need  to  be  changed  and  people  retrained.  In  addition,  since 
knowledge  of  the  processing  done  usually  resides  in  the  office  workers,  it  is 
very  difficult  for  analysts  to  determine  algorithmically  how  data  is  processed 
and  how  it  is  communicated.  If,  however,  this  processing  and  communication  can 
be  captured  by  appropriate  models,  then  it  may  be  possible  to  more  easily 
analyze  what  happens  in  an  office  and  to  restructure  the  office  if  needed.  In 
addition,  if  the  data  processing  in  the  office  is  to  be  automated,  one  would 
like  to  be  assured  that  the  automated  parts  work  correctly. 

Several  models  have  been  developed  with  these  objectives  in  mind.  They  attempt 
to  formally  capture  the  data  flow  and  processing  that  occur  in  the  office  and  to 
analyze  it  to  allow  restructuring  of  an  office  [Cook,  1980;  Ellis  and  Nutt, 
1980;  Ladd  and  Tsichritzis,  1980].  For  example,  if  one  worker  is  overloaded, 
the  load  could  be  split  fairly  easily  "electronically"  by  simply  having  the 
computer  channel  some  of  the  work  to  another  worker's  workstation.  These  models 
can  also  be  used  to  analyze  the  correctness  of  the  workflow  so  that,  for 
example,  some  data  does  not  get  sent  to  a  workstation  from  which  it  never  leaves 
[Nierstrasz  and  Tsichritzis,  1982]. 


3.2  DEVELOPMENT  ENVIRONMENTS 

Although  users  may  eventually  be  able  to  "program"  some  of  their  own 
applications  (cf.  Section  3.3),  complex  and  large  office  applications  will  still 
require  skilled  application  programmers.  While  their  number  may  be  reduced  in 
the  future,  it  will  not  be  possible  to  eliminate  them  altogether.  Thus, 
appropriate  programming  environments  will  need  to  be  provided  that  will  allow 
application  programmers  to  quickly  and  easily  generate  office  applications. 
Traditional  programming  environments  have  proved  inadequate  to  meet  the 
challenge  of  application  development.  New  approaches  will  have  to  be  developed. 

One  approach  that  appears  promising  is  that  of  writing  and  testing  programs 
simultaneously  [Lieberman  and  Hewitt,  1980].  In  the  Tinker  system,  a  user  is 
aware  that  he  is  writing  a  program  using  a  programming  language.  Programs  are 
constructed  by  putting  together  pieces  of  smaller  programs  and  testing  them  at 
the  same  time.  Programs  are  tested  with  examples  as  they  are  being  written. 
Menu  selection  replaces  much  of  the  typing  required  in  constructing  a 
conventional  program.  Thus,  there  is  little  or  no  language  syntax  to 
remember — valid  statements  are  displayed  in  a  menu.  The  immediate  visual 
feedback  from  the  testing  makes  it  easier  to  verify  that  a  sequence  of 
operations  is  correct. 

Another  way  in  which  the  development  environment  can  be  improved  is  to  program 
in  terms  of  the  data  objects  as  they  appear  in  the  user  environment.  This  idea 
is  similar  to  "direct  manipulation"  and  has  been  called  "visual  programming" 
[MacDonald,  1982].  Rather  than  defining  a  data  object  abstractly  and  then 
operating  on  this  abstract  object,  one  manipulates  a  data  object  directly  and 
associates  operators  with  parts  of  the  data  object. 

This  is  the  idea,  for  example,  in  forms-based  programming  environments  [DeJong, 
1980;  Hogg  et  al.,  1982;  Lum  et  al.,  1982;  Luo  and  Yao,  1981;  Rowe  and  Shoens , 
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1982;  Shu  et  al.,  1981;  Fong,  1983].  The  user  displays,  on  the  screen,  an 
electronic  version_  of  a  paper  form  and  then  defines  procedures  on  it  by 
embedding  operators  in  fields  of  the  form  or  by  matching  fields  across  forms. 
If  the  office  procedures  are  simple  enough,  such  a  system  could  be  used  by  an 
office  worker  to  "program*'  the  system. 


3.3  PROGRAMMING  BY  EXAMPLE 


Programming,  in  the  traditional  sense,  is  considered  to  be  a  difficult  skill  to 
learn  for  the  average  person.  This  is  because  programming  involves  a  lot  of 
detailed  syntactic  and  semantic  knowledge  about  the  system.  Computer 
programming  is  an  abstract  endeavor — the  programmer  needs  to  imagine  how  the 
program  will  work  before  he  actually  implements  it.  Because  most  computer 
software  is  general  purpose,  it  is  useful  in  a  large  application  domain  which 
may  make  it  less  than  ideal  for  a  specific  application.  If  the  user  could 
program,  he  could  tailor  the  system  to  his  requirements. 

In  the  previous  section,  wo  saw  that  some  development  environments  are  beginning 
to  appear  that  eliminate  the  need  for  syntactic  knowledge.  However,  in  many 
cases,  and  especially  in  the  case  of  form-based  development  systems,  programming 
is  still  an  abstract  process.  In  real  life,  creating  a  plan  is  an  incremental, 
interactive  procedure.  Similarly,  if  programming  involved  familiar,  concrete 
paradigms  for  the  user  and  was  incremental,  then  users  could  learn  to  program 
and  thus  help  automate  their  use  of  the  system. 

This  is  the  idea  behind  programming  by  example  [Smith,  1977;  Bauer,  1979; 
Halbert,  1981;  Witten,  1981;  Propp,  1983).  The  user  writes  a  program  by  giving 
an  example  of  how  he  would  do  the  same  thing.  The  system  remembers  what  the  user 
is  doing  as  he  executes  the  operations  that  he  would  normally  do. 

This  technique  has  been  used  in  the  Smallstar  system  to  implement  a  prototype 
programming  by  example  environment  [Halbert,  1981].  The  Smallstar  system  is  the 
prototype  from  which  the  Xerox  Star  system  was  developed  [Smith  et  al.,  1982; 
Purvy  et  al.,  1982].  Its  user  interface  is  similar  to  that  of  the  Star  system  in 
which  icons  are  used  to  represent  data  objects,  such  as  forms,  folders  and 
files,  and  system  utilities,  such  as  printers,  filing  cabinets  and  mail  trays. 
The  user  can  open  and  edit  data  objects  or  move  data  objects  to  system 
utilities.  By  recording  the  actions  of  the  user  while  he  is  performing  these 
operations,  an  example  program  can  be  identified.  This  program  then  needs  to  be 
generalized  and  control  constructs,  such  as  iteration,  added  for  it  to  be  useful 
in  many  situations  [Halbert,  1981].  Although  many  problems  need  to  be  overcome 
to  make  such  a  system  useful,  it  is  a  promising  step  towards  letting  users 
program  their  own  applications  thereby  reducing  the  need  for  application 
development  specialists. 
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4.0  ACTIVITY  SUPPORT 


One  of  the  major  ways  in  which  information  is  used  in  an  office  is  to  control  and 
support  the  activities  that  occur  in  the  office.  These  activities  usually 
require  communication  and  coordination  among  several  office  workers  (e.g., 
meeting  scheduling  or  project  control).  They  may  also  require  the  ability  of 
several  office  workers  to  cooperatively  work  on  some  activity.  In  the  past, 
most  office  systems  provided  support  for  individual  workers,  but  support  for 
groups  of  workers  was  lacking.  If  office  workers  are  to  be  more  productive  in 
the  office  of  the  future,  appropriate  group  activity  support  tools  are  required. 
In  addition,  office  systems  must  provide  integrated  environments  in  which  the 
tools  and  the  data  required  by  the  tools  are  available  within  a  common  framework 
(e.g.,  Apple's  Lisa  system  [Williams,  1983]  and  VisiCorp's  VisiOn  system  [Folk, 
1983] 

Most  office  systems  today  are  passive  in  that  all  processing  that  is  done  by  the 
system  needs  to  be  initiated  by  the  user.  This  places  a  great  l)urden  on  the  user 
to  remember  many  details  of  the  processing  done  in  an  office.  In  order  to 
increase  office  productivity,  office  systems  of  the  future  will  have  to  take  an 
active  role  in  initiating  activities  in  the  office.  In  this  way,  the  office 
worker  will  be  freed  from  looking  after  the  housekeeping  aspects  of  office  work 
and  will  be  able  to  concentrate  instead  on  the  challenging  aspects. 


4.1  TASK  MANAGEMENT 


In  order  to  work  effectively,  most  people  need  to  manage  the  time  that  they 
devote  to  specific  activities.  This  is  especially  true  in  an  office  environment 
where  a  great  deal  of  the  activity  involves  scheduled  meetings  [Munson  and 
Sutherland,  1981;  Lerner  and  Sutherland,  1981].  Thus,  an  important  aspect  of 
increasing  office  productivity  is  providing  tools  that  allow  people  to  manage 
their  time  more  effectively. 

Currently,  a  great  deal  of  time  is  spent  on  trying  to  schedule  peoples'  time 
[Munson  and  Sutherland,  1981],  People  each  keep  individual  calendars,  either  on 
their  desks  or  with  them,  and  it  is  often  very  difficult  to  schedule  meetings 
because  of  the  distributed  nature  of  calendar  management.  If  people's  calendars 
were  kept  on-line  and  were  accessible  to  other  people  for  scheduling  purposes, 
more  time  could  be  freed  up  to  do  more  productive  work. 

One  example  of  a  calendar  management  system  is  PCAL  being  implemented  at  MIT 
[Greif,  1982].  PCAL  allows  a  user  to  make,  cancel  or  change  appointments.  It 
keeps  track  of  the  date,  start  time  and  end  time  of  the  activity,  list  of 
participants,  a  brief  description  of  the  activity,  and  any  comments.  Initially 
the  system  supports  only  individual  calendars,  but  its  goal  is  to  support  group 
activities.  This  will  be  made  much  easier  once  all  users  make  use  of  the  same 
calendar  system. 

Workers  in  offices  often  work  on  projects  jointly  as  well  as  individually. 
Calendar  systems  allow  some  aspects  of  joint  project  work  to  be  managed  more 
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effectively.  However,  in  addition,  an  office  system  must  provide  facilities  to 
actually  work  on  projects  jointly.  This  implies  a  whole  range  of  facilities 
from  coordination  of  parts  of  projects,  to  shared  access  to  data,  to  version 
control.  One  effort  that  is  addressing  these  issues  is  the  Officetalk-D  project 
[Ellis  and  Bernal,  1982].  ' 


4.2  EXPERT  SYSTEMS 


One  reason  that  today’s  office  systems  are  passive  is  that  most  of  the  knowledge 
of  what  needs  to  be  done  in  an  office  resides  with  the  office  worker.  That  is, 
the  office  worker  knows  what  steps  are  required  to  accomplish  some  goal,  not  the 
computer  system.  Thus,  current  office  systems  may  provide  tools  to  support  the 
individual  steps  in  a  process,  but  they  do  not  control  the  order  in  which  the 
tools  are  used.  Much  of  this  sequencing  of  steps  is  rather  routine  and  could  be 
automated.  In  addition,  specific  knowledge  of  what  alternatives  to  investigate 
at  any  specific  point  in  a  problem  solving  process  could  also  be  encoded  in  the 
computer.  In  this  way,  the  office  worker  would  be  freed  from  initiating  routine 
processing  steps  and  from  remembering  all  possible  alternatives  for  a  given 
s ituat ion . 

Expert  systems  arc  one  approach  to  solving  this  problem.  An  expert  system  is  a 
computer  system  that  has  deep  experience  in  a  field  of  human  knowledge  [Edelson, 
1982).  As  well,  it  makes  reasoned  judgements  about  the  best  course  of  action  at 
a  given  time  and  can  explain  the  reasoning  that  lead  to  its  conclusions.  An 
expert  system  consists  of: 

1.  a  data  base  that  contains  the  collection  of  information  that  experts  in  the 
field  use  to  make  their  decisions; 

2.  an  inference  scheme  which  is  the  set  of  rules  that  experts  apply  to  the 
informat  ion . 

The  data  base  and  the  inference  rules  are  obtained  from  human  experts  in  the 
field.  Thus,  the  expertise  of  the  system  is  only  as  good  as  the  "experts"  who 
provided  the  data  and  the  inference  rules.  The  advantages  of  using  expert 
systems  are  that  they  can  be  very  thorough  in  their  analysis  of  a  situation  and 
they  can  usually  consider  more  possibilities  than  most  people. 

Expert  systems  have  been  used  primarily  in  the  area  of  medical  diagnosis 
[Amarel,  1981;  Brooks,  1981],  although  one  system  is  being  used  for  computer 
system  configuration  [Edelson,  1982].  In  the  area  of  office  systems,  several 
experimental  efforts  can  be  cited. 

The  Odyssey  system,  implemented  at  the  Xerox  Palo  Alto  Research  Center  [Fikes, 
1981],  uses  knowledge  about  trip  planning  to  assist  a  user  in  filling  out  a 
collection  of  electronic  forms  in  preparation  for  a  business  trip.  The  system 
uses  knowledge  about  the  structure  of  trips,  steps  involved  in  trip  preparation, 
properties  of  dates  and  times,  cities,  and  airports  to  automatically  supply 
certain  trip  data,  to  reslove  ambiguities  in  the  trip  data,  and  to  determine  the 
implications  of  changes. 
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The  office  semantics  project  at  MIT  is  using  knowledge  about  an  organization  and 
about  the  goals  of  an  activity  to  help  the  user  achieve  the  goal.  The  system 
will  advise  a  user  when  a  goal  cannot  be  achieved  because  of  a  contradiction  and 
will  allow  the  user  to  explore  alternate  paths  to  try  to  achieve  a  goal  [Barber, 
1983] . 

With  a  different  emphasis,  the  message  management  project  at  the  University  of 
Toronto  is  attempting  to  embed  knowledge  about  the  routing  of  messages  in  a 
message  management  system  [Mazer  and  Lochovsky,  1983].  The  idea  is  to  associate 
with  a  message  knowledge  about  where  the  message  should  go  next  based  on  such 
criteria  as  current  location,  system  state,  and  message  instance  state. 
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5.0  CONCLUSIONS 


In  this  paper  we  examined  specific  areas  in  which  support  for  office  work  could 
be  provided.  Our  aim  was  to  identify  tools  that  could  be  provided  to  office 
workers  to  support  their  work  rather  than  to  displace  them.  To  this  end,  we 
identified  tools  that  are  being  developed  that  will  allow  office  workers  to  more 
easily  access  and  process  computerized  data,  to  better  understand  their  office 
environment  and  help  computerize  it,  and  to  assist  them  in  managing  their  time 
and  performing  their  office  tasks  more  effectively. 

The  impact  of  the  emerging  office  technology  will  change  the  whole  nature  of 
work  as  we  know  it  in  the  office.  The  technology  will  allow  some  of  the  tasks  in 
an  office  to  be  automated  and  others  to  be  better  supported.  Inevitably  in  the 
transition  period,  as  the  technology  is  introduced,  some  jobs  will  be  lost  as 
the  nature  of  the  office  work  changes  and  some  jobs  deskilled  as  certain  office 
tasks  become  automated  [Taylor,  1981].  However,  the  hope  is  that  the  majority 
of  the  tasks  in  the  office  will  be  enriched  and  made  more  enjoyable  through  the 
increased  support  provided  by  the  computer.  For  example,  secretaries  can  take 
up  a  form  of  programming  or  become  layout  artists  and  format  experts  through  use 
of  the  computer. 

The  way  in  which  the  technology  is  introduced  in  the  office  and  why  will 
determine  to  a  large  extent  how  acceptable  it  will  be  to  the  office  workers 
[Bullen  et  al.,  1982].  It  is  necessary  to  rethink  not  only  isolated  office 
tasks,  but  the  entire  office  work  environment  before  whole-heartily  embracing 
office  automation.  Office  automation  has  the  potential  to  deskill  office  work 
and  make  it  boring  or  to  enrich  it  and  make  it  challenging.  There  are 
opportunities  to  increase  enjoyment  in  office  work.  However,  adequate  planning 
for  office  automation  needs  to  be  done  before  the  technology  is  introduced  if 
this  benefit  is  to  be  attained  [Gregory  and  Nussbaum,  1982] . 

In  the  final  analysis,  the  management  of  the  automation/support  process  will  be 
as  important  as  the  process  itself.  If  the  goal  of  management  is  to  make  people 
happier  as  well  as  more  productive,  then  the  technology  can  free  people  to  do 
more  creative  things.  On  the  other  hand,  if  the  goal  is  productivity  at  any 
cost,  then  the  technology  can  be  an  albatross  around  peoples*  necks. 
Ultimately,  it  is  the  social  concern  that  we  have  with  respect  to  office 
automation  that  will  determine  whether  the  productivity  gains  in  the  office  will 
be  realized. 
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Abstract 

The  paper  outlines  an  Office  Filing  System  which  can  be  used  for  multimedia  mes¬ 
sages.  The  system  uses  signature  techniques  for  fast  filtering.  It  uses  miniatures, 
voice  excerpts  and  a  game  environment  for  effective  browsing  and  selection  of  the 
desired  messages. 
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1 .  Introduction 

Our  objective  Is  to  design  and  implement  a  facility  for  filing  office  objects.  With 
the  advent  of  the  widespread  use  of  message  systems  such  a  facility  Is  very  much 
needed.  As  people  exchange  text  messages,  voice  messages,  records  and  facsimile 
they  will  need  to  file  them  and  retrieve  them  In  a  flexible  manner.  Such  filing  activity 
serves  two  purposes.  First,  it  enables  the  users  to  store  and  retrieve  the  information 
relevant  to  their  own  work.  Second,  it  enables  the  system  to  retain  Information  from 
which  It  can  feed  corporate  data  base  to  augment  the  "corporate  memory"  [MoRo79]. 

We  will  refer  loosely  to  messages  as  the  office  objecfs  related  to  filing.  A  mes¬ 
sage  can  be  a  data  base  record^  a  text  message,  a  voice  message,  or  an  image.  It  can 
also  be  any  combination  of  the  above.  For  instance,  a  message  may  consist  of: 

a)  attribute  values,  e.g.,  date,  sender 

b)  text  part,  e.g.,  letter  contents 

c)  voice  part,  e.g.,  voice  annotation 

d)  Image  part,  e.g.,  digitized  photos 

A  message  consists  of  a  header  which  has  a  unique  id  and  perhaps  rules  related 
to  Its  behavior  [HoGM83].  The  contertts  consist  of  different  sections  of  attribute 
values,  text,  image,  and  voice.  We  want  to  provide  a  facility  for  filing  and  retrieving 
such  multimedia  messages. 

A  simple  way  of  filing  and  retrieving  messages  Is  In  terms  of  labels.  Each  mes¬ 
sage  is  labelled  with  a  name  and  it  is  stored  in  a  separate  file.  It  is  retrieved  through 
a  search  of  the  file  directories,  e.g.,  UNIX  hierarchical  file  directories.  The  approach 
Is  effective  Irrespective  of  the  nature  of  the  message's  contents.  It  Is  equally  appli¬ 
cable  to  data,  text,  voice,  and  Images,  or  any  combinations.  The  management  of 
names,  however,  becomes  difficult  for  the  user  and  It  does  not  work  well  In  the  pres¬ 


ence  of  many  messages. 
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Another  simple  approach  Is  to  file  all  messages  sequentially  and  to  search  them 
sequentially  to  select  the  needed  messages.  It  Is  the  method  used  when  doing  a 
library  search  using  a  microfiche  reader.  The  ordering  of  the  messages  can  facilitate 
the  search,  e.g.,  alphabetic,  chronological,  etc.  The  method  works  well  when  we  don't 
have  many  messages  and/or  the  messages  have  an  order  which  is  very  meaningful  to 
the  user.  However,  it  Is  time  consuming  to  sequentially  scan  all  messages,  when  we 
have  many  messages  and  want  to  access  them  in  many  different  ways. 

A  third  approach  is  to  abstract  some  properties  of  the  messages  and  encapsu¬ 
late  them  In  attribute  values.  The  approach  is  used  in  Information  Retrieval  when 
doing  keyword  searches.  The  search  Is  effected  in  terms  of  a  selection  of  attribute 
values.  The  selection  filter  is  specified  through  a  query  involving  a  Boolean  expres¬ 
sion  of  simple,  attribute  <op>  i/aiue,  conditions.  The  method  is  effective  when  the 
attribute  values  adequately  represent  the  properties  of  the  message  and  when  the 
environment  Is  static.  These  requirements  are  not  easily  fulfilled  when  messages 
have  pictures,  or  voice.  It  Implies  a  priori  knowledge  of  the  properties  which  are 
Important  for  searching  purposes. 

A  fourth  approach  Is  to  retrieve  messages  according  to  a  pattern  present  In 
them  [SaltSO,  FIUI80,  Hask81,  AhKW78].  This  approach  works  well  for  text.  The 
text  part  of  a  message  can  be  qualified  according  to  a  regular  expression  of  strings 
(words,  combinations  of  words)  present  In  them.  For  voice  and  pictures,  however, 
patterns  are  not  easy  to  define  and  they  often  require  complicated  and  time  consum¬ 
ing  pattern  recognition  techniques  [Redd76,  8aBr82,  EHLR80].  Note  that  what  can 
be  a  natural  pattern  for  the  human  eye/ear  Is  not  as  easy  to  pin  down  In  terms  of 
computer-oriented  messages. 

Finally,  a  fifth  approach  to  retrieving  messages  Is  to  encapsulate  their  proper¬ 
ties  In  terms  of  abstractions  which  are  easy  for  the  users  to  recognize.  The  users 
proceed  searching  for  the  messages  with  the  aid  of  these  abstractions.  These 
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abstractions  can  be  closely  related  to  the  message,  e.g.,  a  miniature  Image  of  the 
message.  Abstractions  can  a/so  be  unrelated  to  the  exact  contents  of  the  message, 
e.g.,  a  particular  tune  may  Identify  a  person  or  an  Icon  for  an  Idea.  An  association 
easily  recognized  by  the  user  relates  the  seemingly  independent  abstraction  of  the 
message  to  the  message  Itself. 

In  this  paper  we  would  like  to  deal  with  multimedia  messages.  We  will  use, 
therefore,  a  combination  of  the  above  techniques  for  flexible  message  retrieval.  In 
this  way,  the  facility  would  be  effective  for  each  medium  of  communication  and  it  will 
be  especially  suitable  for  combinations  of  data,  text,  voice  and  pictures. 

Information  retrieval  facilities  consist  usually  of  two  parts;  a  filtering  capability 
and  a  browsing  capability.  Filtering  enables  the  user  to  specify  what  he  would  like  to 
see,  or  equivalently  the  messages  which  he  does  not  like  to  see.  The  browsing  capa¬ 
bility  enables  the  user  to  pinpoint  from  the  filtered  messages  the  ones  which  he 
actually  wants.  In  many  systems  the  browsing  capability  is  only  an  after-thought 
(especially  true  for  data  base  systems).  It  deals  only  with  the  presentation  of  the 
selected  messages  to  the  user.  It  is  not  considered  an  integral  part  of  the  selection. 
In  addition,  the  filtering  and  browsing  are  considered  as  two  independent  and  con¬ 
secutive  steps  without  any  relation  to  each  other.  In  the  case  of  office  filing  the 
browsing  capability  is  very  important.  We  will  consider  it  as  important  for  selection 
purposes  as  the  filtering  capability.  This  approach  Is  needed  because  the  user  filters 
are  rather  vague.  The  user  does  not  adequately  remember  what  he  Is  looking  for. 
Filtering  alone  cannot  pinpoint  the  desired  messages.  In  addition,  voice  and  image 
filtering  according  to  contents  is  difficult  to  implement  because  It  may  imply  pattern 
recognition.  In  this  case  it  is  advantageous  to  use  browsing  rather  than  filtering. 

We  believe  that  the  browsing  aspect  is  a  dual  method  to  the  filtering  for  selec¬ 
tion  purposes.  We  provide  therefor,  "play”  methods  supporting  browsing  in  the  same 
way  that  we  have  access  methods  supporting  filtering.  We  also  allow  filtering  and 
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browsing  to  be  Interleaved.  That  Is,  while  browsing  we  can  modify  the  filter  for 
selection  of  the  messages  we  are  currently  browsing.  In  this  way  filtering  and 
browsing  proceed  concurrently  enabling  the  user  to  pinpoint  the  appropriate  mes¬ 
sages.  The  additional  advantage  of  this  approach  is  that  the  dynamics  of  the 
Interaction  between  the  user  and  the  system  are  greatly  improved.  The  user  does 
not  get  bored  waiting  for  the  filtering,  nor  he  gets  swamped  with  its  results  coming  In 
bursts.  Instead  he  is  provided  with  a  continuous  stream  of  filtered  messages  from 
which  he  can  select,  by  advanced  browsing  methods,  the  messages  he  wants.  The 
browsing  Is  also  implemented  as  an  interesting  game  to  further  appeal  and  retain  the 
Interest  of  the  user. 

2.  General  Design 

Messages  In  our  Office  Filing  System  consist  of  a  unique  Id  and  a  number  of 
fields.  Each  message  has  a  date  field,  a  sender  field  and  a  subject  field  which  are 
attribute  fields.  Attributes  fields  have  a  maximum  length  and  they  take  single  values 
from  a  domain  of  values.  In  addition,  a  message  has  fields  which  are  unstructured 
and  of  variable  length.  These  fields  consist  of  text.  Image,  and  voice  annotations. 
Images  include  graphs,  tables,  captions,  bar  charts,  pie  charts,  diagrams,  and  pic¬ 
tures.  Images  may  appear  anywhere  in  the  message.  Voice  annotations  are  parts  of 
the  message  that  are  used  to  clarify  and  enhance  It.  For  instance,  they  can  be  ver¬ 
bal  comments  about  the  message  or  an  utterance  to  attract  the  attention  of  the 
reader. 

All  IricbftilHg  messagds  dre  filed  Into  a  general  message  file.  The  user  searches 
for  the'  required  messages  guided  by  a  vague  recollection  of  the  contents  of  the 
messages  and  by  a  vague  Image  of  what  the  messages  look  like.  The  user  provides 
initially  a  partial  specification  of  the  message  contents  [Zloo76].  This  partial  specifi¬ 
cation  of  the  desired  messages  acts  as  a  filter.  The  filter  restricts  the  attention  of 
the  messages  In  the  message  file  to  a  manageable  subset.  The  filter  can  be  changed 
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dynamically  by  tightening  Its  specification. 

The  filtering  capability  is  by  no  means  an  exact  one.  The  user  seldom  specifies 
an  accurate  filter.  His  specification  will  allow  more  messages  to  qualify  in  addition  to 
the  ones  he  absolutely  wants.  These  additional  messages  are  eliminated  in  the 
browsing  mode  by  the  user.  To  assist  the  user  in  Identifying  the  appropriate  mes¬ 
sages,  miniatures  and  fasttaik  are  provided.  Miniatures  are  realistic  visual  abstrac¬ 
tions  of  the  messages  which  are  displayed  for  the  user  during  browsing  like  in 
[FeND81].  At  the  same  time  when  the  miniature  appears  in  view  to  the  user,  he  can 
hear  the  fasttaik.  The  fasttaik  is  a  voice  excerpt  associated  with  the  message 
which  highlights  the  message's  meaning.  On  the  basis  of  what  the  user  sees  and 
hears,  he  can  decide  if  the  message  is  one  of  the  ones  he  wants  retrieved.  If  so,  the 
message  corresponding  to  the  miniature  is  displayed  to  the  user  along  with  a  play¬ 
back  of  the  voice  annotations  for  the  messages. 

To  select  the  miniature  to  be  viewed  in  full,  the  user  identifies  the  particular 
miniature  by  shooting  it  down  with  a  dart  gun.  in  the  current  Implementation,  this  dart 
gun  is  stationary  and  the  miniature  is  hit  when  it  appears  within  the  target  ^red  6f 
the  dart  gun.  Using  miniatures  and  fasttaik  rather  than  the  messages  themselves^ 
the  user  can  play  many  more  filtered  messages.  In  this  way  his  browsing  capability  Is 
enhanced.  In  additiori,  the  presence  of  many  more  message  abstractions  enables  the 
user  to  spend  more  time  on  the  more  interesting  candidates.  We  also  plan  to  allow 
the  user  to  control  the  speed  that  the  abstractions  are  played. 

3.  User  Interface 

The  screen  layout  of  our  system  appears  in  Figure  1 


^  Our  Implementation  environment  consists  of  a  SUN  computer  which  provides  one  and  a  half  page  of 
bit-map  display.  The  left  part  Is  a  whole  page  of  message,  while  the  right  Is  half  a  page  of  screen  real 
estate  used  for  menus  and  miniatures. 
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Figure  1 :  Screen  Layout 

The  status  of  the  display  depends  on  the  current  mode,  there  are  three  modes: 

(1)  Create/Append  -  the  user  creates  or  appends  to  the  filter.  This  state  Is 
reflected  by  the  appearance  of  the  filter  template  on  the  left  and  a  menu  area 
to  the  right  of  the  screen. 

(2)  Browsing  -  the  user  Is  playing  the  abstractions  (miniatures  and  fasttalk)  for  the 
messages  that  are  filtered  by  the  system.  Miniatures  are  scrolled  on  the  right 
hand  and  the  filter  remains  on  the  left  part  of  the  display. 

(3)  Viewing  -  the  user  has  just  frozen  the  browsing  of  the  miniatures  to  view  one  of 
the  messages  In  more  detail.  The  expanded  message  appears  on  the  left  and 
the  right  screen  Is  frozen. 

The  fitter  used  by  the  searching  process  is  the  conjunction  of  all  the  restric¬ 
tions  on  the  data,  text,  voice,  and  image  values  of  a  message.  The  template  of  the 
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filter  and  Its  menu  appears  In  the  Filter  Display  and  Menu  areas  as  shown  in  Figure  2: 


sender: 

DATE:  - 


SUBJECT : 


X 


ill. 


f 


IMAGE 

VOICE 


YES 


NO 


DON'T  I 

CflttJ 


YES 


NO 


DW'T 


Command  Line 


CREATE/APPEND 


Figure  2:  Screen  Layout  of  Create/Append 


Restrictions  on  attribute  and  text  values  are  provided  as  values  and  patterns. 
For  each  of  the  attribute  and  text  fields,  a  field  restrictiott  Hlay  be  defined.  Each 
field  restriction  Is  a  conjunction  of  conditions.  The  Syntax  Of  the  field  festricticn  15 
given  by  the  following  pseudo  grammar: 

fleld_restrictlon  =  element  |  fleId_restriction  element 
element  =  string  |  element  '|'  string 
string  =  word  |  wordpart  |  string  word  |  string  wordpart 
word  =  letters 

wordpart  =  •'''letters  |  letters'*',  '*'letters'*' 
letters  =  digit  |  char  (  symbol  |  letters  digit  | 
letters  char  |  letters  symbol 


A  field  restriction  need  not  be  provided  for  each  of  the  data  and  text  field.  In  such 
cases  a  null  field  restriction  for  this  field  is  assumed.  The  field  restriction  Is  entered 
In  the  appropriate  field  entry  on  the  filter  using  a  by  example  approach  [Zloo76]. 
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Restrictions  may  be  placed  on  Images  In  the  form  of: 

(1)  There  are  Images  present  In  the  messages  being  sought.  The  user  specifies  the 
approximate  location  of  where  these  Images  reside  In  the  message  and  their 
tybe. 

(2)  There  are  no  images  present  In  the  messages  being  sought. 

(3)  A  null  restriction  in  which  the  messages  being  sought  may  or  may  not  contain 
Images. 

The  selection  of  the  appropriate  condition  Is  facilitated  by  selecting  the  appropriate 
light  button  beside  the  image  entry  in  the  filter. 

If  the  user  specifies  that  there  are  images  In  the  desired  messages,  he  Indi- 

p 

cates  their  position  by  dragging  an  'x'  Icon  or  an  object  Icon  (e.g.,  graph,  pie  chart, 
etc.)  and  positioning  it  in  the  appropriate  place  on  the  filter  template.  The  'x*  icon 
(representing  any  type  of  Image)  and  the  object  Icons  are  picked  up  from  the  menu. 
Selecting  an  object  Icon  Implies  that  the  desired  Image  Is  represented  by  this  object 
Icon  .  If  within  a  filter  create  or  update  session,  the  user  wants  to  exclude  an  Icon 
placed  during  the  session,  he  can  simply  drag  It  back  Into  the  menu  area  (but  not 
between  sessions)  and  it  will  disappear. 

The  user  specifies  the  voice  restriction  by  selecting  the  appropriate  light  button 
(fdir  voice)  corresponding  to  whether  voice  annotations  is  present,  absent,  or  null  for 
don^t  care. 

Commands  for  the  Office  Filing  System  are  located  in  a  command  line  area  at  the 
bottom  of  the  screen.  The  appropriate  command  is  selected  using  the  appropriate 
light  button.  Different  command  lines  appear  depending  on  what  mode  the  user  is  in. 
The  command  lines  for  the  various  modes  are: 

2 

The  Icon  la  a  graphical  representation  of  an  object  [LoddSSj.  These  Icons  are  similar  to  those  found 
In  the  Star  CSIKH82]  and  the  Apple  Lisa  [WIII83]. 

2 

In  our  Implementation,  an  Image  Is  a  single  Indivisible  object  (e.g.,  pie  chart). 
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Create/ Append  Mode 


rouit  I 


Browsing  Mode 


Create 

Append 

Exit 

Scroll 

Fasttalk 

Filter 

Filter 

Down 

Off 

Viewing  Mode 


Play 

Return  to 

Return  to 

Voice 

Browsing 

Create/Appehd 

When  the  Create  Filter  light  button  is  selected,  it  indicates  that  the  user  is  to 
provide  a  new  fiiter.  A  blank  filter  template  appears  to  the  left  part  of  the  screen 
and  the  user  is  in  the  Create/Append  mode.  After  all  the  restrictions  are  added,  the 
Quit  button  is  selected.  When  the  Append  Filter  light  button  is  selected,  it  indicates 
that  the  user  wants  to  augment  the  existing  filter  (he  is  in  the  Create/Append  mode) 
with  more  restrictions.  The  user  can  now  edit  in  the  restrictions  and  select  Quit  when 
he  is  finished.  To  exit  the  Office  Filing  System,  the  Exit  button  is  selected  while  in 
the  Browsing  mode.  The  Scroll  Down  light  button  when  off  Indicates  that  the  minia¬ 
tures  are  displayed  from  the  bottom  to  the  top  versus  top  to  bottom  (Scroll  Down  is 
on)^.  The  user  can  turn  the  playing  of  the  fasttalk  on  and  off  by  turning  the  ^asttaik 
Off  light  button  off  and  on,  respectively.  As  long  as  this  light  button  is  on,  no  fastiallc 

is  spoken  .  In  the  Viewing  mode,  the  user  can  play  the  voice  annotation  turning  the 
Play  Voice  light  button  on  To  return  to  the  other  two  modes,  the  user  selects  the 
appropriate  return  light  button. 


^  The  speed  of  the  scrolling  Is  limited  due  to  limitations  with  respect  to  how  fast  the  fasttalk  la  spo¬ 
ken. 

®  In  our  current  Implementation,  voice  annotations  and  fasttalk  are  played  back  at  norrnal  speeds. 
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4.  Abstractions  from  Messages 

Information  abstracted  from  the  messages  are: 

(1)  Signatures 

(2)  Miniatures 

(3)  Image  Description 

(4)  Fasttalk 

In  our  system,  we  use  a  signature  technique  as  an  access  method  for  attribute 
and  text  values  [TsCh83].  The  method  is  based  on  superimposed  coding  [ChFa82]. 
A  fixed  length  signature,  which  Is  a  bit  string.  Is  created  for  the  attributes.  A 
separate  signature  is  created  for  each  block  of  the  body.  These  signatures  within 
the  block  signature  are  determined  by  taking  each  non-trivial  word  in  the  body  or  in 
the  attributes,  splitting  It  Into  successive,  overlapping  triplets  of  letters  and  hashing 
each  triplet  into  a  bit  position.  If  the  word  is  too  short,  additional  bit  positions  are 
created  by  using  a  random  number  generator,  which  Is  initialized  with  a  numeric 
encoding  of  the  word.  Thus  a  constant  number  of  bits  corresponds  to  each  non-trivial 
word.  These  bits  are  set  to  one.  The  size  of  the  signatures  and  the  number  of  bits 
per  word  have  been  determined  in  such  a  way,  that  the  performance  of  the  system  is 
optimized. 

To  examine  If  a  given  word  appears  within  a  logical  block  of  the  message,  the 
signature  of  this  block  Is  examined.  The  same  transformation  Is  performed  on  the 
word  and  the  bits  determined  by  the  transformation  are  examined.  If  they  are  alt  one 
the  word  Is  assumed  to  appear  In  the  message.  Otherwise,  the  message  Is  skipped. 
This  access  method  retrieves  supersets  of  the  qualifying  messages.  Parts  of  words 
can  also  be  specified  In  queries.  More  complicated  query  patterns  (including  con¬ 
junctions  and  disjunctions  of  words)  can  be  examined  versus  the  signature  In  an 
obvious  manner. 
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The  miniatures  for  the  messages  are  formed  by  first  taking  each  line  of  text 
within  the  message  and  representing  it  with  a  solid  line.  Then,  the  bit-maps  of  the 
images  are  extracted  and  an  "n”  factor  reduction  is  performed  (i.e.,  reduce  every  "n" 
bits  into  one  bit).  This  reduction  is  sensitive  to  bits  that  are  on.  Hence,  if  a  majority 
of  the  "n”  bits  are  off  then  the  one  bit  is  turned  off.  Otherwise,  the  bit  is  turned  on. 
To  complete  the  miniature,  the  reduced  bit-maps  are  merged  accordingly  with  textual 
portion  of  the  message. 

Simple  Image  descriptions  can  be  abstracted  from  the  message,  such  as  the 
type  of  the  Images  present  in  it  (e.g.,  graph,  table,  bar  chart  etc.)  and  their  position¬ 
ing.  This  information  will  be  automatically  gathered,  since  it  is  reasonable  to  assume 
that  the  image  creation  will  be  conducted  with  the  aid  of  specialized  image  editing 
tools  that  are  aware  of  the  type  of  the  image  being  created. 

In  our  current  system,  the  fasttalk  is  created  manually  by  the  user.  It  contains 
a  short  (one  to  two  seconds  of  talk)  description  of  the  message's  contents.  In  the 
future,  we  are  hoping  to  use  automatic  techniques  to  obtain  a  fasttalk  which 
highlights  thfe  vaice  annotation  of  a  message. 

5.  Implementation 

The  implementation  of  the  Office  Filing  System  is  divided  into  three  processes. 


i nsert 


Pipe  1  ^ 

user 

i nterface 

search 

Pipe  2 

Figure  3;  The  Office  Filing  System  Implementation 
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The  Insertion  process  Is  used  to  add  new  messages  to  the  message  file.  In 
addition,  this  process  generates  the  appropriate  search  aiding  entries  for  the  new 
messages.  The  search  process  will  search  for  messages  satisfying  the  search  filter. 
The  user  interface  process,  as  we  described  earlier,  Is  concerned  with  the  specifica¬ 
tion  of  a  tighter  filter  and  allows  the  user  to  browse  the  miniatures  through  a  game 
playing  environment  and  viewing  a  message  In  more  detail. 

Communication  between  the  user  Interface  and  the  search  process  are  limited  to 
two  uni-directlonal  pipes.  The  user  Interface  process  passes  the  filter  information, 
the  directory  where  the  files  are,  and  the  commands  to  change  the  search  direction 
to  the  search  process  along  pipe  1.  The  search  process  In  turn  passes  to  the  user 
Interface  process  the  messages  that  meet  the  restrictions  of  the  filter  along  pipe  2. 
In  the  rest  of  the  paper  we  will  elaborate  on  the  Insertion  and  searching  capabilities 
of  the  system. 

In  the  current  Implementation  the  user  provides  four  files  to  the  Insert  process. 
These  four  files  contain  various  pieces  of  the  message  (I.e.,  text  and  attributes. 
Images,  voice  annotations,  and  the  message's  fasttalk®).  We  plan  to  use  automatic 
techniques  In  the  future  to  split  a  multimedia  message  into  Its  media  components. 
The  Insert  routine  processes  the  Information  contained  In  the  four  files  and  appends 
them  to  the  appropriate  files  and  relations  of  the  message  file. 

The  message  file  Is  really  seven  files  and  one  data  base  relation.  The  four  input 
fires  are  appended  to  the  corresponding  four  files  of  the  message  file.  The  remaining 
files  and  relations  of  the  message  file  are  created  by  the  Insertion  process.  These 
are  described  as  follows: 

-  An  ASCII  file  Is  provided  as  input  which  contains  the  text  and  attribute  com¬ 
ponents  of  the  message.  The  Insert  routine  generates  the  signatures  entries  for 

the  text  and  attributes  components  of  the  message  and  places  it  Into  the 
£ 

At  this  stage  of  the  Implementation,  we  assume  a  text  editor  has  created  the  text  and  Images  portion 
of  the  message  and  a  simple  voice  editor  has  created  the  voice  files. 
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signature  file  of  the  message  file. 

-  A  file  containing  the  positioning  and  size  Information  for  the  images  present  In  the 
message  is  provided  as  input.  It  also  contains  the  bit  maps  for  these  images  and 
information  about  the  image  type.  From  the  ASCII  file  and  this  file,  the  miniature  is 
created  and  placed  into  the  miniatures  file  of  the  message  file.  The  positioning 
information  along  with  the  Information  about  the  image  types  is  stored  by  the 
insert  routine  into  a  database  relation  of  the  message  file. 

-  Two  files  are  provided  that  contain  the  voice  annotation  and  the  fasttalk  portion 
of  the  message,  respectively.  For  the  initial  implementation,  the  files  contain  ana¬ 
log  signals  of  the  corresponding  voice  annotation  and  fasttalk,  and  are  stored  on  a 
separate  direct  addressable  audio  storage  device  [Inst82]. 

-  The  last  file  of  the  message  file  is  a  pointer  file.  It  contains  Information  about  the 
other  six  files  of  the  message  file.  Each  entry  In  this  file  gives  the  location  and 
size  of  each  portion  of  the  message  in  the  corresponding  files. 

The  "Insert"  routine  consists  of  the  three  subprocedures  that  update  the  tiles 
and  relations  of  the  message  file  based  on  the  input  files  (refer  to  Figure  4).  It  also 
updates  the  pointer  file  according  to  the  Information  returned  by  them. 


Figure  4:  Insert  PfOcedUfd  Outlih^. 
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The  "search"  routine  calls  three  search  procedures  to  progressively  Isolate  the 
messages  that  satisfy  the  filter  conditions.  The  sequence  of  calls  and  Inputs  shown 
In  Figure  6. 


a  mtfssag*  in 
tMssaga  fil* 


■Msag*  satisflM 

filtar 


Figure  6:  Search  Procedure  Outline. 

Each  message  Is  passed  through  the  three  search  procedure  sequentially  and  the 
respective  medium  restriction  specified  in  the  filter  are  checked.  The  messages  that 
finally  pass  'search  text'  are  those  that  qualify  under  all  the  medium  restrictions 
contained  In  the  filter  Including  the  one  for  the  text  and  attributes. 

The  'search  image'  routine  first  checks  the  entry  In  the  pointer  file  to  see  If  the 
message  contains  the  minimal  number  of  Images  that  are  required.  If  so,  the  routine 
verifies  that  the  positioning  of  the  image  Is  indeed  within  the  minimum  rectangle  for 
the  images  and  the  types  of  the  Images  match  those  specified  In  the  filter  by  check¬ 
ing  the  corresponding  database  relation.  If  the  absence  restriction  Is  specified,  the 
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search  process  merel>  checks  to  see  that  there  are  no  images  in  the  message. 

The  'search  voice;'  routine  requires  only  a  search  for  the  presence  or  absence  of 
voice  annotations  in  the  messages. 

The  'search  text'  routine  retrieves  the  signatures  for  the  incoming  message  and 
examines  if  the  message  satisfies  the  restrictions  on  the  text  and  attribute  values. 

The  results  of  the  searcher  is  a  filtered  subset  which  Is  passed  to  the  the  user 
interface  for  browsing.  The  miniatures  for  these  messages  are  displayed  and  the 
fasttalk  are  played.  When  the  fasttalk  of  a  given  messaged  is  played,  the 
corresponding  miniature  of  the  message  is  highlighted  by  a  box  on  the  screen. 

6.  Concluding  Remarks 

The  Office  Filing  System  outlined  in  this  paper  is  being  implemented  using  UNIX 
on  a  SUN  computer  [ThRi78].  The  SUN  [Sun  82]  is  a  MC68000  based  system  that 
combines  high-performance  graphics,  processing,  and  networking  capabilities  In  a 
desk-top  workstation.  It  has  a  high  resolution  (1024  by  800  points)  bit-map  display 
that  can  show  two  pages  of  text  and  graphics  of  a  reasonable  resolution.  A  hand¬ 
held  pointing  device  called  a  mouse  facilitates  input  of  graphical  Information.  The 
SUN  UNIX  operating  system  is  based  on  the  Berkeley  4.2bsd  version  of  UNIX  and  the 
ARPA  IP/TCP  protocols  [Sun  82].  The  Ethernet  local  area  network  connection  allows 
SUN  workstations  to  share  resources  and  to  access  such  services  as  electronic  mall, 
file  storage,  and  printing. 

We  are  using  the  Instavox  RA-12  Rapid  Access  Audio  Unit  [Inst82]  for  storing 
voice  messages.  Voica  messages  are  stored  on  1  5-lnch  diskettes,  each  of  which 
can  contain  about  27  minutes  of  speech.  However,  voice  messages  are  represented 
in  analog  form  and,  as  such,  changes  in  playback  speed  are  not  allowed.  We  are 
planning  to  Incorporate  the  capability  of  increasing  the  playback  speed  of  fasttalks 
so  that  a  faster  scanning  rate  of  the  messages  can  be  achieved. 
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We  use  signatures  as  an  access  technique  to  speed  up  text  search.  We  are 
also  considering  the  use  of  special  processors  to  support  our  system.  A  basic 
requirement  is  that  the  processor  must  be  able  to  handle  both  structured  and 
unstructured  files.  We  are  planning  to  use  the  Irrtel  iDBP  database  processor 
[Inte82]  because  it  provides  facilities  for  managing  both  structured  and  unstructured 
files.  For  instance,  It  provides  'JOIN'  operations  for  relating  structured  files  together 
and  'CONNECT'  operations  for  relating  structured  files  and  unstructured  files  together 
[Lowe82].  Therefore,  separate  structured  and  utislruciured  files  (t;.y.,  mehio  head¬ 
ing,  text,  image  and  voice  parts)  can  be  CONNECTed  together  and  manipulated  as  an 
integrated  message.  Although  the  IDBP  can  be  used  for  full  text  search,  we  can  also 
employ  signatures  to  further  enhance  the  performance.  Finally,  the  iDBP  can  be  used 
as  a  file  server  connected  to  an  Ethernet  in  order  to  allow  sharing  of  the  facility  by 
several  users. 

The  following  are  in  our  opinion  the  highlights  our  system. 

a)  It  stores  and  retrieves  mixed  media  messages. 

b)  It  interleaves  filtering  and  browsing  for  flexible  message  selection. 

c>  ft  uses  signatures  as  an  access  method  for  text  selection. 

d)  It  uses  miniatures  and  fasttaik  as  abstractions  to  aid  the  user  in  pinpointing 
faster  the  desired  messages. 

e)  It  uses  information  about  Images  in  terms  of  their  type  and  their  positioning. 

f)  It  uses  a  game  to  Improve  the  user  Interaction  and  retain  his  interest. 

It  should  be  noted  that  the  selection  in  terms  of  attribute  values  and  text  pat¬ 
terns  Is  mainly  based  on  filtering  and  appropriate  access  methods.  The  selection  in 
terms  of  voice  and  Images  Is  mainly  based  on  playing  fast  abstractions  In  a  game 
environment.  In  this  way,  the  user's  ability  for  fast  and  effective  browsing  is 


enhanced. 
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ABSTRACl^ 

A  message  management  system  (MMS)  is  a  system  that  provides  for 
uniform  and  "intelligent"  communication  and  processing  of  messages.  So  far, 
prototype  MMSs  provide  mainly  for  messages  consisting  of  structured  and 
unstructured  text.  Incorporation  of  other  types  of  data  such  as  Image  data 
Is  also  needed.  In  this  paper,  we  present  the  design  of  a  data  model  and  a 
database  suitable  for  image  data.  The  data  model  represents  images  in 
terms  of  a  high-level,  semantic  description  of  their  contents  rather  than  a 
low-level,  pixel-oriented  description.  We  also  present  the  desicn  of  a  graph¬ 
ical  user  Interface  and  discuss  the  syntax  of  the  allowable  operations.  The 
image  database  management  system  is  part  of  a  prototype;  MMS  being 
developed  at  the  University  of  Toronto. 

1.  INTRODUCTION 

A  message  management  system  (MMS)  is  a  computer-based  system  for  managing  structured 
messages.  It  integrates  the  facilities  of  computer-based  message  systems  (CBMSs)  and 
database  management  systems  (DBMSs)  [11].  A  typical  MMS  consists  of  many  powerful, 
standalone  personal  workstations  connected  in  a  communications  network  and  able  to 
exchange  and  process  local  and  global  information.  This  information  consists  of  diverse 
types  of  data  Including  structured  text  messages,  unstructured  text  n  essages,  image  data 
(drawings  or  pictures)  and  voice.  A  MMS  should  be  able  to  handle  all  the  above  data  types 
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In  a  uniform  way. 


MMvSs  are  based  on  DBMSs  which  havo  traditionally  been  designed  to  handle  only 
alphanumeric  data.  For  image  data,  particularly,  the  many  differences  between  the  two  data 
types  make  the  use  of  a  conventional  DBMS  to  handle  image  data  Inefficient  and  cumber¬ 
some.  On  the  other  hand,  existing  Image  Information  Systems  (lISs)  in  specific  applications 
(e.g.,  image  processing,  geographic  applications,  etc.),  use  a  DBMS  to  aid  in  managing  Image 
data  by  extending  the  DBMS  and  building  a  special  system  on  top  of  it  [1],  [2],  [3],  [4], 
[^]>  [S]*  [lO]*  [13].  However,  lISs  that  follow  this  approach  usually  have  two  major  disad¬ 
vantages: 

a)  They  still  use  query  languages  much  more  suited  to  conventional  alphanumeric  databases 
and 

b)  They  are  so  complex  that,  in  many  of  them,  some  of  the  basic  operations  can  be  per¬ 
formed  only  by  experts. 

Furthermore,  these  systems  emphasize  a  low  level  description  of  an  image  (i.e.,  points,  lines, 
polygons,  intensity,  color,  etc.). 

In  the  MMS  setting,  provision  has  to  be  made  for  images  of  arbitrary  complexity  and  diver¬ 
sity.  Therefore,  the  most  suitable  description  would  be  one  that  emphasizes,  not  the  Image 
elements  as  they  appear  in  an  image,  but  rather  the  semantic  information  that  these  ele¬ 
ments  carry.  Furthermore,  a  suitable  image  data  model  should  allow  the  user  to  provide  the 
additional  information  needed  for  each  image,  and  to  organize  it  In  a  way  that  permits 
retrieval  and  manipulation  of  images  by  referencing  their  semantic  structure,  that  is,  the 
image  elements  they  contain  and  the  relationships  among  them. 

A  prototype  MMS,  that  incorporates  several  types  of  data  and  provides  a  uniform  interface 
to  the  user,  is  currently  being  developed  at  the  University  of  Toronto.  In  this  paper,  we  will 
deal  with  the  design  of  an  image  subsystem  for  this  MMS  consisting  of  an  image  data  model, 
an  image  database  and  a  suitable  user  interface.  Application  areas  where  such  a  system 


might  prove  useful  arc;: 


a)  Police  applications  for  archiving  photographs  of  criminals  or  photographs  of  scenes 
relevant  to  a  case. 

b)  Art  galleries  or  museums  might  organize  data  on  their  collections  of  items  with  such  a  sys¬ 
tem  . 

c)  A  warehouse  might  organize  its  inventory  with  such  a  system,  so  that  a  retrieved  item 
would  be  displayed  along  with  an  Image  of  its  exact  location. 

2.  THE  IMAGE  DATA  MODEL 

Consider  an  image  i  belonging  to  the  set  of  all  images  /.  A  unique  image  id  distinguishes 
each  Image  in  this  set.  /  can  be  partitioned  into  smaller  subsets,  Ti,  not  necessarily  disjoint, 
which  include  Images  of  the  same  type,  that  is,  images  with  similar  structure.  An  Image  is 
characterized  by  its  Image  id  and  its  type. 

An  Image  can  be  considered  as  a  collection  of  objects,  that  Is,  the  primitive  picture  elements 
recognized,  and  a  collection  of  relationships  among  these  objects.  Examples  of  objects  are 
PERSON,  HOUSE,  TREE,  BOLT,  etc.  and  examples  of  relationships  are  PERSON  in  front  of 
HOUSE,  HOUSE  includes  CHAIR,  etc. 

Image  decomposition  is  the  process  of  defining  for  each  image  the  objects  it  consists  of 
and  the  relationships  among  the  objects.  An  object  can  be  thought  of  as  an  image  itself; 
therefore  it  can  be  further  decomposed  into  other  objects.  These  objects  are  said  to  belong 
to  a  lovDer  level.  Objects  at  a  lower  level  can  be  decomposed  into  other  objects  and  so  on. 
Relationships  between  objects  of  the  same  or  different  type  at  various  levels  are  permitted. 

An  image,  thus  decomposed,  can  be  represented  as  a  directed,  labelled  graph  (or  hyper¬ 
graph)  where  the  nodes  correspond  to  objects  and  the  labelled  edges  correspond  to  the 
relationships  among  the  objects.  In  the  following,  we  shall  assume  binary  relationships  only 
between  two  objects.  Each  object  (node)  gets  decomposed  into  another  graph  at  a  lower 
level.  In  this  sense,  we  can  say  that  the  set  of  objects  forming  the  decomposition  of 
another  object  constitute  a  hypergraph.  Schematically  we  can  draw  a  decomposition  as  in 


fig.  1  where  the  arrows  point  in  the  direction  of  the  relationship.  In  such  a  graph  the  con¬ 
struction: 

OBJ1 - - >  OBJ2 

means  (obj,1)  relationship  (obj,2)  (i.e.,  HEAD  above  TRUNK). 

Before  we  proceed,  we  have  to  distinguish  between  the  terms  image  type  and  image 
instance,  between  the  terms  object  type  and  object  instance  and  between  the  terms  rela¬ 
tionship  type  and  relationship  instance. 

An  image  type  is  a  generic  entity  representing  all  images  that  contain  objects  and  relation¬ 
ships  among  the  objects  from  a  predefined  set  of  object  and  relationship  types.  In  addition, 
the  objects  and  the  relationships  among  the  objects  are  from  a  set  of  object  types  and  per¬ 
mitted  relationship  types  specific  to  this  image  type.  The  information  about  an  image  type  is 
contained  in  its  graph  description.  (Thus,  an  image  belongs  to  a  type,  say,  A  If,  when  decom¬ 
posed  Into  objects  and  their  relationships,  the  graph  formed  is  a  subgraph  of  the  graph 
describing  images  of  type  A.)  Image  types  represented  by  a  disconnected  graph  are  permit¬ 
ted.  The  intuitive  meaning  is  that  we  are  interested  only  in  the  objects  that  the  image  con¬ 
tains  and  not  in  the  inherent  structure  (relationships)  of  the  picture  elements. 

An  image  instance,  on  the  other  hand,  is  an  ordered  collection  of  pixel  values  (denoting 
intensity  and/or  color).  An  image  Instance  may  be  of  more  than  one  Image  type.  Namely,  it 
can  be  decomposed  in  more  than  one  way  if  this  serves  the  application. 

An  object  type  is  the  generic  entity  denoted  by  the  object  name.  It  can  be  thought  of  as 
the  set  of  all  object  instances  that  have  similar  properties  (i.e.,  the  object  type  PERSON  is 
the  set  of  all  person  object  instances).  Each  object  type  has  associated  with  it  a  set  of 
attributes  that  characterizes  it  (e.g.,  the  object  type  PERSON  may  have  the  attributes  COM¬ 
PLEXION,  HEIGHT,  HAIR  COLOR,  etc.).  An  object  type  may  be  found  at  various  levels 
throughout  the  image  types.  For  example,  consider  the  object  type  PERSON  which,  among 
other  decompositions,  gets  decomposed  into  the  object  type  HEAD.  Some  image  types  may 
contain  the  object  type  PERSON  (at  level  1 )  and  consequently  the  type  HEAD  (at  level  2)  as 


a  decomposition  of  PERSON,  while  others  may  contain  HEAD  (at  level  1 )  as  a  basic  picture 
element. 

An  object  instance  has  a  unique  id  within  its  type.  For  example,  the  person  instance  #  3  is 
unique  within  the  object  PERSON  but  is  different  from  the  house  instance  §  3  which  is  also 
unique  within  the  object  HOUSE.  The  uniqueness  of  the  object  Instances  and  the  image 
Instances  Is  necessary  so  that  we  can  readily  identify  and  correlate  them. 

A  relationship  type  is  a  generic  entity  that  represents  a  certain  spatial  relationship  (e.g., 
positional,  comparative,  etc.),  in  the  Informal  sense,  between  two  object  types.  For  exam¬ 
ple,  the  relationship  type  in  front  of  carries  the  notion  of  a  position  relationship  between 
the  two  participating  object  types,  in  the  sense  of  object  type  1  is  in  front  o/ object  type 

2.  The  above  definition  of  a  relationship  type  is  general  enough  to  allow  for  any  two  object 
types  to  participate  in  a  relationship  type. 

A  relationship  instance  is  the  extension  of  the  relationship  type  and  is  considered  to  be  an 
ordered  pair  of  object  Instances  whose  object  types  are  related  through  a  relationship  type. 

3.  THE  IMAGE  DATABASE 

So  far,  we  have  discussed,  in  a  somehow  abstract  sense,  how  to  organize  the  image  decom¬ 
position  and  the  Image  database.  In  an  actual  system  implementation  we  need  two  kinds  of 
information: 

a)  We  need  Information  about  the  image  types,  the  object  types,  the  relationship  types 
among  the  object  types  and  the  image  type  decomposition. 

b)  We  need  Information  about  the  actual  Image  Instances  stored,  the  object  instances  they 
contain  and  the  relationships  among  the  objects  In  an  image.  As  well,  we  need  information 
about  the  object  instances  themselves. 

Information  of  the  first  type  corresponds  to  schema  data  (meta-data)  in  traditional  DBMSs 
and  is  kept  in  the  Image  Schema  (IS).  Information  of  the  second  type  corresponds  to  the 
actual  data  stored  by  a  traditional  DBMS  and  is  kept  in  the  Image  Database  (IDB). 


3.1  Irnaftc  Schema 


The  IS  holds  information  about  the  image  types,  the  object  types  and  the  permitted  relation¬ 
ship  types  among  the  object  types.  This  information  is  organized,  as  discussed  previously.  In 
the  form  of  a  graph.  Let  us  consider  now  a  meta-type  called  Image  Types  which  Is  the  set 
of  all  image  types  and  a  meta-type  called  Object  Ihjpes  which  is  the  set  of  all  object  types. 
These  are  related  as  shown  in  the  Entity-Relationship  Diagram  in  fig.  2. 

The  includes  relationship  type  represents  the  fact  that  a  given  image  type  is  characterized 
by  the  presence  of  specific  object  types.  Since  an  image  type  may  include  many  object 
types  and  also  one  object  type  may  be  included  in  many  image  types,  the  relationship  is  N:M. 

The  includes  relationship  relationship  type  represents  the  fact  that  an  image  type  is  also 
characterized  by  the  presence  of  relationship  types  among  the  object  types  of  which  it  is 
composed  (e.g.,  image  type  snapshot  Includes  relationship  :  object  type  PERSON 
in_Jront_gf  object  type  HOUSE).  Again,  it  is  obvious  that  this  is  an  N:M  relationship 
between  Image  Types  and  pairs  of  Object  Types.  Therefore,  it  is  a  ternary  relationship 
between  Image  Types  and  Object  Types  as  shown  in  fig.  2. 

The  decomposes  into  relationship  type  represents  the  fact  that  an  object  type  can  be  a 
collection  of  other  object  types  (i.e.,  PERSON  decomposes_into  HEAD,  TRUNK,  etc.).  Since 
an  object  type  can  be  decomposed  into  more  than  one  object  type  and  an  object  type  may 
be  a  component  of  more  than  one  object  type,  the  relationship  is  N:M. 

3.2  Image  Database 

The  IDB  contains  the  actual  images  and  their  decomposition  as  entered  by  the  user.  The 
decomposition  is  checked  against  the  structure  imposed  by  the  IS  and  if  found  compatible,  it 
is  accepted.  The  structure  of  the  IDB  follows  that  of  the  IS  except  that  now  we  are  dealing 
with  image  instances,  object  instances  and  the  relationships  among  the  objects.  The 
Entity-Relationship  Diagram  for  the  IDB  is  shown  in  fig.  3. 


Since  we  are  dealing  with  images  we  also  introduce  the  definition  of  graphical  attributes 


which  take  graphical  values.  An  example  of  an  object  with  graphical  attributes  may  be: 
object  name:  EYES;  attributes:  SHAPE  graphical,  COLOR  graphical,  DIMENSIONS 
chard  0);  attribute  values:  SHAPE  [/\,  O,  <  >,  V/j  COLOR  [red,  ...,  blue]  DIMEN¬ 

SIONS  [1,123]. 

4.  THE  USER  INTERFACE 

In  this  section,  we  present  the  user  interface  for  the  image  subsystem  that  is  compatible 
with  other  user  Interfaces  to  our  prototype  MMS  [6],  [1  2].  Since  the  IS  and  IDB  are  a  sub¬ 
system  of  the  MMS,  the  user  should  experience  a  smooth  transition  when  using  the  various 
parts  of  the  system.  We  therefore  adopt,  as  much  as  possible,  the  operation  syntax  of 
other  user  Interfaces  within  our  MMS. 

The  operations  on  an  image  database  can  be  categorized  into  User  Ofyera.tions  and  Image 
Database  Administrator  (IDBA)  Operations.  The  normal  user  is  allowed  to  update  only  the 
IDB  while  the  IDBA  may  modify  both  the  IDB  and  the  IS. 

4.1.  Screen  layout 

The  screen  layout  is  as  shown  in  fig.  4.  The  image  display  area  is  used  to  display  images 
and  the  system  specification  forms  (see  Section  4.2.).  Images  that  have  been  retrieved  or 
are  ready  to  be  inserted  are  shown  here.  Furthermore,  certain  Information  which  is  displayed 
in  a  form  format  (e.g.,  attribute  information  about  an  object)  is  also  shown  here. 

The  system  operation  area  at  the  top  of  the  left  side  of  the  screen  Is  used  for  displaying, 
via  light  buttons,  system  operations  such  as  cancelling  an  operation  or  exiting  from  the  sys¬ 
tem. 

The  system  server  area  at  the  bottom  of  the  left  side  of  the  screen  is  used  to  display  the 
Icons  of  system  server  instances  such  as  GARBAGE  CAN,  FILE  CABINET,  and  PRINTER.  Moving 
data  to  a  system  server  causes  the  appropriate  service  (deletion,  storage  or  printing)  to  be 
initiated.  System  servers  are  used  here  in  the  same  way  as  In  [6]. 


The  area  denoted  sys;f(^m  m(^.ssa(je  arc.a  is  used  for  displaying  system  messages  such  as 
error  or  status  messages. 

The  three  areas  labelled  Onjp.VTS,  RI'HATIONSHIPS  and  TYPES  are  used  to  display  the 
icons  of  the  object  types,  the  relationship  types  and  image  types  known  to  the  system.  The 
user  can  manipulate  these  icons  by  changing  their  position  within  the  respective  area,  copy¬ 
ing  them  to  a  working  area,  deleting  them,  etc.  If  there  are  more  icons  than  can  be  con¬ 
veniently  displayed,  the  user  can  scroll  this  area  of  the  screen  in  either  direction.  The  scrol¬ 
ling  facility  is  provided  in  all  display  areas  of  the  screen. 

In  the  three  columns,  if  a  light  button  (i.e.,  OEJPXTS,  REIATIONSHIPS or  TYPES)  is  selected, 
then  an  operation  that  pertains  to  the  whole  class  of  object  types,  relationship  types  or 
image  types,  respectively,  is  performed  (e.g.,  define  a  new  object  type).  If  on  the  other 
hand,  an  icon  of  a  specific  item  is  selected,  say,  the  object  type  PERSON,  then  the  scope  of 
the  operation  is  limited  only  to  this  item. 

Finally,  the  imagp.  s/cptch  arp.a  (ISA)  is  the  user's  sketchpad.  Here  he  forms  his  query  by 
gathering  together  objects,  forms  qualifications  by  specifying  attribute  values,  etc.  When 
inserting  an  image,  its  decomposition  is  first  formulated  in  the  ISA. 

4.2.  Specification  Forms 

To  facilitate  the  formulation  of  queries  in  a  simple  and  unified  vyay,  as  well  as  the  definition 
of  new  object  types  and  new  relationship  types,  the  system  supports  three  types  of  forms: 
the  Object  Specific atinn  Form  (OSF),  the  Relaiionship  Specification  Form  (RSF)  and  the 
Im.n.ge  Specification  Form.  (fSF). 

An  OSF  (fig.  5)  is  associated  with  each  object  type  or  instance.  It  includes  a  name  field, 
several  attribute  fields,  a  decomposed-into  field,  a  component-of  field  and  an  icon  sketch 
field.  There  are  also  two  light  buttons  to  be  used  with  the  attributes:  TYPE  ar\6  VALUE. 
The  TYPEW^hX  button  is  used  to  look  at  or  define  an  attribute  type.  The  light  button  VALUE 
is  used  to  look  at  or  define  the  range  of  values  of  a  specific  attribute  (if  the  OSF 
corresponds  to  an  object  type)  or  the  value  of  this  attribute  (if  the  OSF  corresponds  to  an 


object  Instance).  The  decoTnposRd-inf.o  field  contains  the  components  of  this  object.  To 
define  a  component  object,  the  user  points  to  the  dscomposed-into  field  and  then  copies  an 
object  (type  or  instance)  into  this  field  as  described  below.  The  component-of  fie\d,  simi¬ 
larly,  contains  the  parent  object  of  this  object.  Finally,  the  icon  field  is  a  grid  highlighting 
the  object  Icon.  A  new  icon  can  be  defined  for  an  object  by  drawing  along  the  grid  lines. 

An  empty  OSF  (all  fields  undefined)  can  be  filled  In  so  as  to  define  a  new  object  type.  It  can 
also  be  used  in  a  query  to  retrieve  all  object  types  with  the  specified  attribute  names  and 
range  of  values  or  icons  or  to  retrieve  all  images  with  objects  having  the  specified  attribute 
values.  In  a  query,  an  undefined  field  matches  all  values. 

If  the  attribute  is  graphical,  then  when  the  VALUE  button  is  pressed  and  the  attribute  is 
selected,  a  pop-up  menu  appears  displaying  all  possible  DOMAINS  of  graphical  values.  After 
the  user  selects  a  DOMAIN,  he  is  shown  all  possible  values.  If  he  is  defining  a  new  object 
type,  he  can  select  the  range  of  values  of  this  particular  attribute  by  selecting  the  desired 
graphical  values.  If,  on  the  other  hand,  he  is  specifying  a  query,  the  domain  Is  known  and, 
therefore,  he  is  immediately  shown  the  corresponding  graphical  values  for  him  to  choose  from 
(fig.  5). 

An  (fig.  6)  is  associated  with  each  relationship  type  or  instance.  It  Includes  a  name 
field,  the  name-of-the-inverse  field  and  two  object  fields  displaying  the  icons  of  the  partici¬ 
pating  object  types. 

If  an  RSF  refers  to  a  relationship  type  which  Is  to  be  defined,  then  all  fields  are  undefined. 
The  user  may  enter  the  name  of  the  relationship  type  and  its  inverse,  as  well  as  two  object 
types  to  serve  as  an  example  of  the  use  of  this  relationship  type.  The  icons  of  the  example 
object  types  will  be  displayed  when  a  query  about  this  relationship  type  is  issued. 

If  a  blank  RSF  is  used  to  specify  a  relationship  instance,  the  user  has  to  select  the  partici¬ 
pating  object  Instances.  To  do  so,  he  selects  first  the  object  instance  icon  and  then  places 
it  either  to  the  left  or  to  the  right  of  the  arrow  in  the  RSF.  These  are,  respectively,  the  posi¬ 
tions  of  the  first  and  the  second  object  Instance  that  participate  in  the  relationship  (i.e.. 


object  1  relationship  object  2).  If  the  relationship  is  bidirectional,  then  of  course,  the  rela¬ 
tive  placement  of  the  two  object  icons  does  not  matter. 

An  ISF  (fig.  7)  is  associated  with  each  image  type  or  instance.  It  includes  a  name  field,  an 
objects  field  and  a  relationships  field.  The  name  field  contains  the  name  of  the  respective 
image  type.  If  the  ISF  corresponds  to  an  image  type,  then  the  objects  field  contains  one 
entry  for  each  object  type  included  in  this  image  type  and  the  relationships  field  contains 
one  entry  for  each  relationship  type  contained  in  this  image  type.  Each  object  type  entry 
consists  of  the  object  type's  name,  its  icon  and  the  minimum  and  maximum  number  of  objects 
allowed  to  participate  in  the  relal  ionship.  Each  relationship  type  entry  consists  of  the  rela¬ 
tionship  type's  name  and  the  pictorial  example  in  the  respective  RSF. 

An  empty  ISF  is  used  to  define  a  new  image  type.  The  user  has  to  enter  the  image  type's 
name  and  select  the  object  and  relationship  types  to  be  included.  This  is  done  by  selecting 
first  the  object  icons  and  copying  them  into  the  objects  field,  and  second  the  relationship 
type  icons  and  copying  them  into  the  relationships  field. 

If  the  ISF  corresponds  to  an  image  instance,  ttien  it  contains  the  information  about  this 
image  instance's  decomposition.  The  objects  field  contains  the  object  instances  occurring  in 
this  image  instance  and  the  retatwnships  field  contains  the  relationship  instances  among 
the  object  instances  included  in  this  image  instance. 

Since  an  image  is  displayed  in  the  image  display  area,  its  corresponding  ISF  has  to  be 
displayed  in  the  ISA.  In  order  to  allow  flexibility  In  the  formulation  of  an  image  instance's 
decomposition  or  the  specification  of  a  query,  the  whole  ISA  is  considered  to  map  exactly 
onto  the  ISF  and  the  user  may  freely  position  the  object  or  relationship  instance  icons  any¬ 
where  within  this  area. 

4.3.  User  Operations 

The  user  Interacts  with  the  system  via  a  mouse  and  a  keyboard.  He  can  select  an  item  on 
the  screen  by  pressing  a  button  on  the  mouse  while  the  cursor  is  within  the  appropriate  light 


button  or  Icon.  A  typical  operation  scenario  proceeds  as  follows.  The  user  copies  some 
objects  into  the  ISA,  gives  values  to  some  of  their  attributes  and  then  points  to  the  icon  or 
corresponding  light  button  of  the  entity  he  wants  to  manipulate.  For  example,  if  he  queries 
an  image  he  will  press  the  light  button  IMAGES,  while  if  he  deletes  an  object  type  he  will 
select  the  icon  for  the  appropriate  object  type.  According  to  what  has  been  selected,  a 
pop-up  menu  will  appear  displaying  to  the  user  all  the  allowable  operations.  This  menu  may 
be  different  for  the  IDBA,  since  he  enjoys  special  privileges.  After  the  pop-up  menu  has 
appeared  the  user  is  expected  to  select  one  of  the  alternatives  displayed.  An  EXIT  light 
button  is  provided  in  all  menus  so  that  the  user  can  cancel  the  current  item  selection.  Each 
time  an  operation  is  Issued,  whatever  is  in  the  ISA  or  the  image  display  area  is  taken  into 
account  If  the  operation  so  dictates.  This  provides  on  cfficicmt  and  uniform  way  of  passing 
the  parameters  of  the  operation. 

Class  level 

Class  level  operations  allow  new  image,  object  or  relationship  types  to  be  defined.  The 
class  level  operations  are  available  only  to  the  IDBA.  After  selecting  one  of  the  light  buttons 
TYPES,  OBJECTS  or  RELATIONSHIPS,  the  following  menu  options  are  available: 

COPY:MXox  the  user  has  filled  in  a  blank  ISF,  OSF  or  RSF,  via  the  EDIT  operation,  the  COPY 
operation  is  used  to  create  the  defined  image  type,  object  type  or  relationship  type.  The 
user  subsequently  points  to  a  location  in  the  respective  display  area  and  the  icon  for 
the  newly  defined  item  appears  at  the  specified  location. 

EDIT:NfXor  selecting  the  EDIT  operation,  a  blank  ISF,  OSF  or  RSF  appears  in  the  image 
display  area.  The  user  fills  in  the  specification  form  as  described  In  section  4.2. 

Type  level 

Type  level  operations  allow  new  image,  object  or  relationship  instances  to  be  created,  image 
types,  object  types  or  relationship  types  to  be  updated,  queried  or  deleted  and  the  icons  to 
be  repositioned.  After  selecting  an  image  type,  object  type  or  relationship  type,  the  follow- 


ing  menu  options  are  available: 


COPY.f or  an  image  type,  selecting  COPY  causes  a  new  instance  of  this  image  type  to  be 
created  (e.g.,  to  assign  the  type  to  a  certain  image  or  to  specify  a  query  qualification). 
The  Icons  of  the  object  and  relationship  instances  created  appear  in  the  ISA.  Values  may 
need  to  be  assigned  to  these  object  and  relationship  instances,  by  manipulating  their 
OSFs  and  RSFs,  before  they  are  further  used.  For  an  object  type  or  relationship  type, 
the  COPY  operation,  followed  by  a  location  in  the  ISA,  is  used  to  create  an  object  or  rela¬ 
tionship  instance  with  the  icon  of  the  object  or  relationship  appearing  at  the  specified 
location.  All  attribute  fields  for  the  object  are  initially  undefined.  The  user  has  to  expli¬ 
citly  supply  them  by  issuing  an  operation  at  the  instance  level.  If  the  location  for  an 
object  type  is  a  dp.com'posed-into  field  in  another  object  type's  OSF,  then  the  selected 
object  type  becomes  a  component  of  this  object  type.  Automatically,  the  second  object 
type  is  inserted  in  the  component- of  field  of  the  selected  object  type,  because  it  is  now 
one  of  its  parent  objects.  In  all  cases,  if  the  location  is  a  system  server,  then  the 
corresponding  operation  will  be  executed  (e.g.,  printing  a  hardcopy  of  an  ISF,  OSF  or  RSF). 

EDITilhQ  EDIT  operation  is  available  only  to  the  IDBA  and  appears  in  the  menu  only  when  the 
image,  object  or  relationship  type's  icon  is  in  the  ISA.  By  issuing  this  operation,  an  ISF, 
OSF  or  RSF  is  displayed  in  the  image  display  area  and  the  IDBA  is  allowed  to  modify  any  of 
its  fields  (e.g.,  to  delete  or  insert  new  object  types  and/or  relationship  types).  The 
modification  is  not  actually  made  until  the  image,  object  or  relationship  type  is  moved 
back  into  its  corresponding  display  area. 

QUPRY:QUEKi  is  used  to  find  out  descriptive  information  about  the  selected  image,  object  or 
relationship  type  (e.g,,  what  objects  and/or  relationships  an  image  type  is  composed  of). 
The  corresponding  ISF,  OSF  or  RSF  appears  in  the  image  display  area  and  the  user  can 


browse  through  it. 


MOVEfXhis  operation  is  used  to  change  the  position  of  the  image,  object  or  relationship 
type's  icon  within  the  IMAGES,  OBJECTS  or  RELATIONSHIPS  6\sp\Qiy  area,  respectively, 
send  the  image,  object  or  relationship  type  to  a  system  server  or  update  it.  The  user 
selects  MOVE  and  then  points  to  a  location.  Valid  locations  are  the  IMAGES,  OBJECTS  or 
RELATIONSHIPS  6\sp\3iy  area,  the  ISA  and  the  system  sfjrver  icons.  If  a  location  in  the 
IMAGES,  OBJECTS  or  RELATIONSHIPS  6\sp\ay  area  is  selected,  the  corresponding  icon  is 
repositioned  there.  If  a  location  within  the  ISA  is  selecteJ,  the  icon  is  repositioned  there 
and  the  image,  object  or  relationship  type  can  be  update^!  by  issuing  the  EDIT  operation. 
After  the  information  about  the  item  has  been  updated,  Ihe  icon  has  to  be  MOVEd  back 
from  the  ISA  into  the  corresponding  display  area  for  the  actual  update  to  take  place.  As 
long  as  the  icon  stays  in  the  ISA,  this  item  cannot  be  used  for  any  purpose  (e.g.,  to  for¬ 
mulate  a  query)  other  than  those  stated  above.  If  the  icon  is  MOVEd  to  a  system  server 
Icon,  the  appropriate  action  takes  place.  The  deletion  and  update  operations  are  avail¬ 
able  only  to  the  IDBA. 

Instance  level 

a)  image  instance 

There  is  the  notion  of  a  current  image  and  its  decomposition  (If  any)  that  is  directly  manipu¬ 
lated  by  the  image  operations.  If  the  current  operation  does  not  involve  images,  the  current 
image  Is  not  changed.  If  an  image  is  retrieved  and  displayed  on  the  screen,  it  becomes  the 
current  image.  COPY  and  MOVE  refer  to  the  current  image,  v/hile  RETRIEVE  sets  the  current 
image.  After  selecting  an  image,  the  following  menu  options  are  available: 

COPY:The  COPY  operation  is  used  to  get  a  hardcopy  of  an  image.  To  do  this,  one  selects  the 
PRINTER  icon  after  selecting  the  COPY  operation. 

RETRIEVE:The  RETRIEVE  operation  is  used  to  retrieve  images  from  the  system  servers. 
Before  retrieving  images,  the  user  has  to  enter  a  qualification  into  the  ISA.  The  system 
interprets  the  presence  of  object  and  relationship  instanc<js  as  primitive  expressions  of  a 
qualification  involving  only  ANBs.  It  is  very  difficult  to  devise  a  scheme  supporting  ORs 


or  a  mixed  qualification  of  ANI^  and  ORs  along  the  operation  syntax  we  have  discussed 
so  far.  Therefore,  if  the  user  wants  an  OR  condition,  he  has  to  issue  separate  retrieval 
operations.  However,  there  is  a  simple  method  to  allow  for  N07^  In  a  query  qualification. 
The  user  may  cross  out,  with  the  cursor,  an  object  instance  or  relationship  instance  and 
this  is  interpreted  as  "retrieve  all  images  not  containing  the  crossed  out  object  or  rela¬ 
tionship  instances". 

The  result  of  a  query  is  a  set  of  qualifying  images.  The  first  image  returned  will  be  the 
current  image.  Along  with  the  image  itself,  the  image  decomposition  is  also  accessible  to  the 
user  and  can  be  displayed  in  the  ISA. 

.Mong^'do  the  image  there  is  a  scroll  area  with  two  arrows  oointinq  up  and  down.  If  the 
user  selects  one  of  these,  the  next  or  previous  image  retrieved  Is  displayed  and  becomes 
the  current  image.  If  there  is  no  next  or  previous  image,  the  previously  displayed  image 
remains  on  the  screen. 

MOVR:The  MOVE  operation  is  used  to  send  the  image  to  one  of  the  system  servers.  To 
daLote  the  image  one  moves  it  to  the  GARBAGE  CAN  icon.  To  insert  or  update  and  image, 
one  moves  it  to  the  FILE  CABINt  T  icon. 

Before  inserting  an  image,  the  user  must  have  defined  the  image  decomposition  in  the  ISA. 
This  Is  done  by  creating  object  instances  in  the  ISA  (by  copying  the  object  type  icons  into 
the  ISA)  and  then  defining  relationships  among  them  and  giving  values  to  their  attributes.  If 
the  ISA  Is  empty,  the  image  is  considered  to  be  not  yet  decomposed.  If  the  NULL  object  is 
included  in  the  decomposition,  then  no  matter  what  else  is  in  the  ISA,  the  image  Is  considered 
to  be  explicitly  non-decomposable. 

To  update  an  image,  it  must  first  have  been  retrieved  via  the  RETRIEVE  operation.  When  an 
image  is  retrieved,  it  is  displayed  and  its  decomposition  is  available  in  the  ISA.  The  user  can 
select  any  of  the  displayed  objec;t  instance  icons  and  alter  any  field's  attribute  value  or 
redefine  the  relationships  among  the  object  instances.  After  changing  the  decomposition  in 
the  ISA,  the  update  is  performed  as  indicated  above. 


b )  object  and  relationship  instance 

Object  and  relationship  instance  operations  are  used  to  create  copies,  or  to  update,  delete 

and  reposition  instances.  After  selecting  an  object  or  relationship  instance,  the  following 

menu  options  are  available: 

COPY:Jiye  COPY  operation  is  used  to  create  a  copy  of  an  object  or  relationship  instance 
within  the  ISA  or  to  print  information  about  the  object  or  relationship  instance  by  COPYing 
It  to  the  PRINTER  system  server. 

EDIT:The  EDIT  operation  Is  used  to  further  specify  an  object  or  relationship  instance  for  use 
In  a  query  or  an  Image  insertion.  It  is  also  used  to  change  the  OSF  or  RSF  for  an  object  or 
relationship  instance.  The  corresponding  OSF  or  RSF  is  displayed  in  the  image  display 
area. 

MOVE.fAOyE  is  used  to  either  reposition  the  object  or  relationship  instance  within  the  ISA  or 
to  send  it  to  a  system  server  (e.g,,  delete  it  by  MOVEing  it  to  the  GARBAGE  CAN). 

ISA  Operations 

It  is  also  possible  to  select  the  ISA  and  to  perform  the  following  operations  on  it: 

COPY.'COPy  is  used  to  create  a  copy  of  the  ISA  (e.g.,  to  print  or  save  it).  COPY  is  used  when 
we  want  to  save  the  present  state  of  the  ISA  without  clearing  it. 

RETRIEVE:  The  RETRIEVE  operation  is  used  to  retrieve  saved  ISA's  from  system  servers 
(e.g.,  from  a  FILE  CABINET  or  the  GARBAGE  CAN). 

AfOVE’.The  MOVE  operation  is  used  to  send  the  ISA  to  one  of  the  system  servers.  Moving  it 
to  the  GARBAGE  CAN  Icon  deletes  it  (clears  the  ISA).  Moving  it  to  the  FILE  CABINET  icon 
allows  ISA's  to  be  saved  for  further  use.  It  can  be  retrieved  subsequently  by  the 
RETRIEVE  operation.  Saving  ISA's  is  useful  if  we  want  to  experiment  with  queries,  start¬ 
ing  from  a  given  checkpoint,  by  making  small  changes  to  the  query  sketch  each  time,  try¬ 
ing  out  different  patterns. 


System  Server  Operations 


The  user  can  get  a  list  of  the  objects  that  reside  in  a  system  server  by  querying  it.  Other¬ 
wise,  system  servers  can  be  used  as  target  locations  for  other  operations  (e.g.,  retrieve, 
move  or  copy).  A  detailed  description  of  the  system  servers  available  in  our  MMS  is  given  in 
[6]. 

b.  CONCLUSIONS 

A  message  in  an  actual  office  environment  may  consist  of  many  different  types  of  data  (e.g. 
structured  text,  unstructured  text,  images  and  voice).  So  far,  existing  MMSs  handle  only 
structured  and  in  some  sense  unstructured  text.  On  the  other  hand,  lISs  are  tailored  to  the 
specific  applications  they  serve  and  handle  images  at  a  very  low  level. 

In  this  paper,  we  presented  the  design  of  an  image  subsystem  that  allows  for  the  high  level 
description  of  images  [5].  An  image  is  considered  as  a  collection  of  objects  and  relation¬ 
ships  among  these  objects.  The  decomposition  of  an  image  into  objects  and  relationships 
among  the  objects  allows  the  representation  of  images  of  varying  complexity  and  diversity. 
A  user  interface  that  allows  the  user  to  use  graphical  means  to  manipulate  the  images  is 
also  provided. 

The  image  subsystem  is  part  of  a  MMS  currently  under  development  at  the  University  of 
Toronto  [6],  [12].  The  system  is  being  implemented  in  the  C  programming  language,  under 
UNIX,  on  a  SUN  personal  workstation.  The  image  schema  and  image  database  are  being 
implemented  as  relations  using  the  MISTRESS  DBMS  [9J. 
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Abstract 

In  this  paper  we  provide  estimates  of  the  number  of  sequential  and  random 
block  accesses  required  for  retrieving  a  number  of  records  of  a  file  when  the 
distribution  of  records  in  blocks  of  secondary  storage  is  not  uniform.  We  show 
how  these  results  apply  to  estimating  sizes  of  joins  and  semi-joins.  We  prove 
that  when  the  uniformity  of  placement  assumption  is  not  satisfied  it  often  leads 
to  pessimistic  estimates  of  performance.  Finally  we  show  a  recursive  estima¬ 
tion  of  the  probability  distribution  of  the  number  of  blocks  containing  a  given 
number  of  records. 

1.  Introduction 

In  response  to  a  query  a  number  of  blocks  have  to  be  transferred  from 
secondary  storage  to  main  memory.  Estimates  of  the  number  of  blocks  of 
secondary  storage  that  have  to  be  transferred  in  main  memory  are  important 
in  physical  data  base  design  ([Yao77a].  [BatoryBl],  [Tsichritzis  and  Christo- 
doulakis83]).  data  base  system  performance  evaluation  ([SevcikBl],  [Christo- 
doulakisBl]).  and  query  optimization  ([Schnciderman  and  Goodman76],  [Yao 
and  DeJong7B]).  In  addition,  the  distribution  of  the  number  of  blocks  contain- 
ing  a  given  number  of  records  is  important  in  the  analysis  of  performance  of 
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concurrency  control  ([Ries79],  [Potier  and  LeblankBO]),  and  the  estimation  of 
rotational  delays  [Siler?6].  Penally  estimates  of  sizes  of  joins  and  semi-joins  are 
especially  important  in  distributed  query  optimization  ([Kerschberg  et  al.BO], 
[Bernstein  et  al.  Bl]).  It  is  our  thesis  that  data  base  system  performance 
analysis  can  not  be  based  on  inaccurate  estimates  of  these  parameters. 

Estimates  of  these  parameters  are  knovm  for  uniform  distributions.  How¬ 
ever,  in  several  occasions  it  is  the  case  that  distributions  are  not  uniform.  For 
example  attribute  value  distributions  in  a  given  domain  often  follow  Zipf's  law 
([Kerschberg  et  al.BO],  [Siler  76]).  In  the  case  of  records  placed  in  blocks  of 
secondary  storage,  several  factors  may  contribute  to  non-uniform  distributions 
of  the  records  of  a  file  over  the  blocks  of  the  secondary  storage.  Some  of  these 
eu^e  clustering  of  different  record  types,  variable  record  lengths,  insertion  eind 
deletion  activity  and  file  creation  method  (hashing  for  example).  Finally,  when 
text  is  placed  in  blocks  of  secondary  storage  the  number  of  distinct  non-trivial 
words  [Tsichritzis  and  ChristodoulakisBB]  varies  among  blocks  of  secondary 
storage. 

In  this  paper  we  generalize  several  existing  theoretical  results  for  estimat¬ 
ing  expected  values  of  these  parameters  to  include  non-uniform  distributions. 
Then  we  prove  that  in  several  occassions  uniformity  results  to  pessimistic  esti¬ 
mates  of  these  parameters.  Finally  we  give  iterative  formulae  for  the  calcula¬ 
tion  of  the  probability  distributions  of  the  blocks  containing  a  given  number  of 
records. 

2.  Block  Transfers  for  Given  Placement 

Let  ij  be  the  number  of  records  in  a  block  j  of  a  file.  Since  we  can  see 
non-trivial  words  of  a  text  file  as  variable  length  records,  the  discussion  of  this 
section  applies  to  text  files  as  well.  In  this  case  ij  is  the  number  of  distinct 


non-trivial  words  in  the  blocks'  of  the  text  file. 

We  assume  in  this  section  that  ij  is  given  for  j  =  l,  ■  ■  ■  M,  where  M  is  the 
number  of  blocks  of  the  file.  In  an  existing  file  this  statistics  can  be  extracted 
with  a  sequential  scan  of  the  file,  or  by  using  a  dense  primary  index.  Let  m  be 
the  maximum  possible  number  of  records  per  block  {O^ij  <  m,j  =  l.  •  •  •  M).  The 
maximum  possible  number  of  records  per  block  can  be  found  from  the  smallest 
possible  record  size  (in  bytes),  and  the  size  of  a  block  (in  bytes).  Thus  our 
model  allows  for  fixed  and  variable  size  records  in  a  file,  for  files  where  the 
number  of  records  per  block  is  variable  due  to  insertions  and  deletions,  for  files 
where  the  number  of  records  per  block  is  variable  due  to  the  process  that  was 
used  for  creating  the  file  (hashing  for  example)  as  well  as  for  the  case  that 
records  from  more  than  one  files  are  intermixed  with  records  of  the  file  under 
consideration. 

Random  Accesses 

We  first  examine  a  non- replacement  model  {[Yao77b],  [ChristodoulakisBl]). 
Consider  a  query  Q  for  which  k  records  of  the  file  qualify.  We  assume  that  any 
selection  of  k  records  from  the  n  records  of  the  file  has  the  same  probability 

where  C*  stands  for  the  combinations  of  n  objects  taken  fc  at  a  time.  Let  Xj 

be  a  random  variable  associated  with  a  block  j.  Xj  assumes  the  value  1  if  the 
block  contains  any  of  the  k  records  selected  by  Q,  and  0  otherwise.  The 
number  of  blocks  randomly  accessed  for  selecting  the  k  records  from  the  file  is 

The  expected  number  of  random  block  accesses  Bj.  required  for 
i=i 

retrieving  k  qualifying  records  from  the  file  is  therefore 

J  =  1  3-1 

where  P{Xj=l)^P{Xj)  is  the  probability  that  block  j  contains  any  of  the  k 


records. 


F{Xj)  is  function  of  the  number  ij  of  the  records  of  the  file  in  the  block 


Thus 


P{X,)  =  1  - 


Ck 


.n-ij 


and 


Br=^ 

j=\ 


(1) 


or 


m 


pfi  -H 


(2) 


1=0  Cfc 

where  is  the  number  of  blocks  in  the  file  which  contain  exactly  i  records 


(2  il-i=n). 


i=0  i=0 


Both  (l)  and  (2)  reduce  to  Yao’s  formula 

=  - 


(3) 


when  the  number  of  records  in  every  block  is  constant  and  equal  to  b  [Yao77b]. 


We  provide  an  Iterative  formula  for  (2): 


Set 


v.>ir  ^4* 

F  =  — —  F  =  —  =  1 

^k  ^k 


Then 


n-k-i 


Cf}  n-i 


Fi 


and 


m 


1=0 

Thus  0{m)  operations  are  needed  to  calculate  Bj..  Similar  iterative  evaluations 
can  be  given  for  the  resulting  closed  form  formulae  involving  combinations 


throughout  the  paper. 

We  consider  next  a  retrieval  with  replaceTnent  model;  records  that  are 
retrieved  are  placed  back  ([Cardenas75],  [ChristodoulakisBl]).  Another 
interpretation  of  this  model  may  be  that  an  ordered  set  of  k  possibly  duplicate 
records  is  retrieved  [CheungBS].  In  addition  it  provides  a  good  approximation  of 
the  non-replacement  model  when  the  number  of  records  per  block  is  large 
[Yao77b].  The  expected  number  of  block  accesses  in  this  model  when  the 
number  of  records  per  block  is  not  constant  is 

,=i  " 

Sr=t  kH-d-  ~f)  (4) 

t=0  ^ 

When  the  number  of  records  per 'block  is  constant  (4)  reduces  to  Gardena’s  for¬ 
mula  [Cardenas75]; 

Br  =  (5) 

It  can  be  shown  that  the  expected  number  of  random  block  accesses  of  the 
non-replacement  model  is  greater  or  equal  to  the  expected  number  of  block 
accesses  of  the  replacement  model.  Indeed; 

n-i,-  n— 1,  — 1  n— i,  — A:  +  l  ,ri— i,-  . 

-± - =  - L.  * - 1 - ♦  .  .  .  ♦ - 1 — - <( - L.)fc 

CQ  n  n  —  1  n—k-\-l  n  '  ' 

The  result  follows  by  comparing  (2)  and  (4).  The  special  case  of  uniform  place¬ 
ment  is  discussed  in  [Yao77b], 

Sequential  Accesses 

In  this  section  we  estimate  the  expected  block  accesses  for  finding  k 
records  in  sequentially  accessed  files  (lYao  77a],  j Schnciderman  and  Good- 

man76]).  Let  bo  the  total  number  of  records  in  the  first  j  blocks  of 

r  =  l 

the  file.  The  probability  that  exactly  j  blocks  have  to  be  examined  sequentially 


in  order  to  find  all  the  k  qualifying  records  is 


dj  -  dj  ‘ 


= 


(e.g.  edl  possible  selections  of  k  records  from  the  j  first  blocks  minus  all  possi¬ 
ble  selections  of  k  records  from  the  j -I  first  blocks  divided  by  the  total 
number  of  selections  of  k  records).  Thus  the  expected  number  of  blocks  Bg 
that  need  be  accessed  sequentially  in  order  to  retrieve  the  k  qualifying  records 
is 


K  di-di-' 


;=i 


Or 


B.  =  M  - 


■'k  ^k 


t  d'-' 

ifi _ 

cr 


(6) 


In  the  special  case  of  uniform  placement  of  exactly  b  records  in  each  block,  (5) 
reduces  to  Yao’s  formula  [Yao7?a]: 


A/ 


B.  =  M- 


j=i 


CQ 


Next  we  derive  estimates  of  the  sequential  block  accesses  using  the 
replacement  model.  The  probability  that  all  k  retrievals  will  be  from  the  first  tj 

.  Thus  the  expected  sequential  accesses  using  the  replacement 


records  is 

model  is 


n 


B,  = 

J  =  i 


k 

f  y 

tj-i 

k‘ 

n 

71 

\  » 

(6) 


or 


u-\ 


B,  =:  M 


iii 


(9) 


AgEiin  since  <  (-^)*^  it  follows  that  the  expected  accesses  for  the  non- 

replacement  model  is  greater  or  equal  to  the  expected  block  accesses  for  the 
replacement  model. 


3.  Block  Transfers  when  Placement  is  not  Known 

When  statistics  of  the  distribution  of  the  number  of  records  per  block  does 
not  exist  (is  not  maintained  or  the  file  does  not  exist  yet)  it  may  be  possible 
that  it  is  derived  by  knowing  the  process  that  creates  the  file.  Let  P^,  i  =  Q,m 
describe  the  probability  distribution  of  the  number  of  records  per  block  in  the 
file.  Then  the  expected  random  block  accesses  is  given  by; 


m  -  i 


1=0 


(10) 


Let  Pj{t)  be  the  probability  that  in  the  first  j  blocks  of  the  file  exist  exactly  t 
records.  qjt{i)  be  the  probability  that  the  jlh  block  contains  exactly  i  records 
given  that  the  j  first  blocks  contain  t  records,  and  /^ti(fc)  be  the  probability 
that  exactly  j  blocks  of  the  file  need  be  examined  sequentially  in  order  to  find 
all  the  k  qualifying  records  given  t  and  i.  Then 


j=l  t=l  i=l 


(11) 


where 


(12) 


Given  Pi,  Pj{t)  and  equations  (10),  (11)  and  (12)  can  be  used  for  calculat- 
ing  the  expected  random  and  sequential  block  accesses  for  retrieving  k 
records. 


When  various  record  types  involving  records  of  different  lengths  are  inter¬ 
mixed  the  number  of  records  per  block  will  vary  with  serious  implications  on 


system  performance  [Teorey  and  Das76],  [Tcorey  and  OberlanderTB].  The  same 


will  be  true  when  the  file  is  formed  from  records  of  a  single  record  type  but  the 
length  of  records  Follows  a  distribution.  In  [Teorey  and  0berlander78]  it  is 
show'n  how  to  estimate  the  probability  distributions  and  the  number  of  blocks  M 
of  a  file  when  the  frequencies  and  the  sizes  in  bytes  of  the  various  record  types 
involved  are  known.  Thus  (10),  (11),  and  (12)  can  be  directly  applied  in  this 
environment.  Similar  analysis  cam  be  done  for  a  single  record  type  but  variable 
length  records. 

Another  environment  where  these  distributions  can  be  easily  derived  is  a 
hashed  file  environment  where  each  block  is  selected  with  the  same  probability 

( ■^)  each  time  that  a  record  is  inserted.  Assuming  no  overflows,  a  binomial  dis- 
M 

tribution  may  be  used: 

where  n  is  the  number  of  records  inserted  in  the  file  so  far.  Similarly 

Pi(t)  =  cT (I  - 

and 

=  j)'-‘ 

In  the  following  we  will  examine  an  environment  where  records  of  fixed  size 
are  randomly  placed  in  the  slots  of  the  address  space  of  the  file.  This  for  exam¬ 
ple  may  model  the  record  placement  in  blocks  of  a  file  after  a  large  number  of 
insertions  and  deletions. 

A  Random  Placement  Model 

The  axidress  space  of  a  file  is  the  ordered  set  A  =  (l,8,  •  •  •  N).  A  single  ele¬ 
ment  of  A  is  called  linear  address.  Let  n<N  be  the  number  of  records  in  the 
file.  A  placement  of  the  n  records  of  the  file  is  a  set  of  n  distinct  linear 
addresses.  In  a  random  placement  m.odel  the  n  records  of  the  file  are  randomly 


placed  among  the  N  linear  addresses  and  each  possible  placement  is  equally 
probable.  (We  assume  in  this  section  fixed  length  records.) 


In  this  model  the  probability  distribution  Pi  can  be  calculated  as 


Pi 


r’N-m 
'^n  -i 


'N 


‘■'n 


lllUS 


(13) 


Br  =  M 


'N-m 


_  ^  (T  ck-i  ^ 

2-J  r^N 


i=0 

For  the  sequential  access  case  we  obtain 


(14) 


Piit)  = 


cl"'  C^lzl”' 


'N 


and 


(15) 


9jt(^)  = 


CT 


ci 


m 


(16) 


Thus 


* 


t=k 


(17) 


Example  1 

Consider  a  file  of  M=3  blocks  each  having  m=2  positions  such  that  the  size 
of  the  address  space  of  the  file  is  N=M*rn=6.  Let  n  =  3  records  be  placed  ran¬ 
domly  in  these  6  possible  positions.  Let  k=2  records  being  selected.  Using  (13) 

and  (14)  we  calculate  Po=  Pi=^.  P2=  7^-  Thus  Br  =  ~^.  These  numbers 

20  20  20  60 

are  verified  in  figures  (1)  and  (2)  where  all  possible  placements  are  shown.  If  a 
constant  number  of  b=l  records  existed  in  each  block  then  using  (3)  we  calcu- 


For  the  sequential  access  case  using  (ih),  (16).  and  (17)  we  calculate 


■P3(3)  =  1.  Also  9,2(2)  =  1,  922(1)  =  !-,  ?22(S)=^ 

923(1)=!-.  923(2)=|-.  933(1)=!|-.  933(2)=!!-  Thus  5,  =  .^.  These  numbers  are 
verified  in  figures  (3)  and  (4).  If  a  constant  number  b=l  of  records  existed  in 

_  ^  0Q 

each  block  then  using  (7)  we  calculate  5*  =  -——. 


4.  Sizes  of  Joins  aund  Semi-joins 

Let  /?  be  a  relation  and  A  an  attribute  of  /?  which  takes  values  on  an 
ordered  finite  domain  of  values  D  =  (Vi,  •  ■  ■  V^).  In  this  section  we  assume 
independence  of  attribute  values  of  the  attributes  of  a  relation. 

The  value  vector  is  defined  such  that  7\  is  the  number  of 

tuples  in  R  which  have  value  for  attribute  A  (i  =  l.  •  •  =  n).  The 

i  =  l 

number  of  tuples  in  the  equi-join  on  an  attribute  A  of  two  relations  R  and  R' 
with  value  vectors  =  (n-i  •  •  •  rijj)  and  F’/i  =  (n'l  •  •  •  on  attribute  A  is  cal¬ 
culated  as 


SJ  = 

i  =  l 

[Kershberg  et  al.BO].  If  k  and  k'  records  are  selected  from  each  of  the  relations 
before  the  join,  then  the  expected  size  of  the  join  can  be  easily  shown  to  be 


i.1. '  w 


iTi 


(18) 


When  semi-joins  are  used  in  the  query  evaluation  method  [Bernstein  et  al 
81],  in  order  to  choose  a  good  query  evaluation  strategy  it  is  important  to  have 
good  estimates  of  the  number  of  distinct  values  remaining  in  the  joining 
domain  as  well  as  good  estimates  of  the  tuples  remaining  in  a  relation  after  a 
semi-join  is  performed  [Bernstein  et  al.8l].  By  semi-join  R'[A=A>R  we  mean 
the  join  of  R'  and  R  on  attribute  A  followed  by  the  projection  on  the  attributes 


of  R.  It  can  be  performed  by  sending  the  distinct  values  R'j^  of  R'  in  A  to  the 
sites  containing  R  and  eliminating  those  tuples  of  R  which  do  not  contain  a 
value  in  R'a 

The  value  probability  vector  Pa  =  {Pi,  '  '  '  ,Pm)  its  name  indicates  pro¬ 
vides  an  estimate  of  the  probability  that  a  given  value  in  the  joining  domain  is 
non-zero  at  any  point  of  the  query  evaluation  process.  It  is  created  and  main¬ 
tained  as  follows: 

Creation.  If  r^=0  then  Pi=0  else  Pi  =  l 
Update'. 

a)  selections  or  semi-joins  on  other  attributes  of  R  such  that  k  records 
remain  in  R'. 


Pi^l- 


CD 


(19) 


b)  projections  on  A  or  supersets  of  A  do  not  affect  Pi 


c)  selection  on  A  of  the  form  A='Vi',  A<'Vi',  AO'Vi  set  Pi=0  for  the 

components  of  P/ which  do  not  qualify. 

d)  semi-join  R'[A=A>R  with  another  relation  R'  with  probability  vector 
P^'  {Pi,  ■  ■  ■  'Pm')  produces  a  new  vector 

{P,P{.  ■  ■  ■  .PmPu') 


The  expected  number  of  distinct  values  remaining  in  the  joining  domain  A 
after  a  semi-join  (or  join)  is 


D 


=  t  PiPi 


(20) 


i  =  l 


The  expected  number  of  tuples  of  R  remaining  after  a  semi-join  (or  join)  is 


^  <  =  i 


(21) 


where  k  is  the  number  of  records  isolated  from  selections  or  semi-joins  on 


other  domedns. 


Figure  5  shows  an  example.  The  distribution  of  the  number  of  tuples  of 
three  relations  R\,R2  and  yi’3  on  a  common  domain  D  arc  shown.  We  assume  for 
this  example  a  query  evaluation  strategy  which  performs  a  selection  on  Ri  (for 
which  3  records  qualify)  followed  by  a  semi-join  Ri[A=A>R2  followed  by  a  semi- 
join  R^A'=^A>R2-  The  estimated  number  of  distinct  values  and  semi-join  sizes 
are  shown  m  the  figure  for  two  different  ways  of  estimating  join  sizes. 

We  note  here  that  in  order  to  reduce  the  number  of  calculations  required, 
attribute  values  in  a  joining  domain  can  be  grouped  into  classes  so  that  the 
members  of  each  class  have  approximately  the  same  number  of  records  per 
value. 

&,  Implications  of  Non-Uniform  Placement 

In  this  section  we  compare  different  placements  of  a  number  of  objects  in  a 
number  of  buckets  and  we  draw  some  conclusions  for  the  expected  block 
accesses  and  semi-join  sizes  in  a  data  base  environment. 

Definition:  A  vector  a=(ai,  •  •  ,a^)  with  is  said  to  majorize  a  vec¬ 
tor  b=(6i,bg,  •  ■  •  ,b)J)  with  b  {^b^-  •  •  •  if  ^  ^  ^  bi  for  k  =1  to  M-1  and 

i=l  i=l 

fi  u 

S  a,  =  S  6,. 

1=1  i=l 

Intuitively  if  a  vector  a  majorizes  another  vector  b.  then  the  components 
of  a  deviate  more  from  uniformity  than  the  components  of  b.  In  the  following 
Oj  and  bj  will  be  non-negative  integers  for  all  i. 

nneorem:  Let  a=(tti.  •  •  a^)  and  b=(bi,  •  •  •  bjy)  be  two  vectors  satisfying  the 

property  that  tij’s  and  b^'s  are  nonnegative  integers  and  when  the  components 
of  a  and  b  are  rearranged  such  that  ai>a2>  •  •  •  >ajy>0  and 
then  a  majorizes  b.  Let  be  the  cost  function  (l),  where  x  is  an  M- 


dimensional  vector.  Then  .^(a)<.^(b), 

Proof 

We  first  observe  that  given  a  vector  d  we  can  permute  its  components 

without  affecting  ^(d).  Thus  without  loss  of  generality  we  will  assume  that  the 

given  vectors  a  and  b  are  such  that  Let  a 

and  b  satisfy  a  majorizes  b.  The  distance  l|a-b||  of  the  two  vectors  is  defined  to 
M 

be  lla-bll  =  2  where  L  is  non-negative  integer. 

i  =  l 

The  following  inequality  holds  for 

+  CT  <  (22) 

Indeed 

rn  _  +  1  1  — 

Mfe  ^  ‘-A:  - 


n  n  +  1  jn  m-1 

n  (i)  -  n  (^)  +  fi  (i)  -  n 

n  +  l-k  +  l 


n-Jfc  +1 


m  -Jt  4  1 


m-1 

n 

m  -fc 


k 

m-1 


nm-l 

(i)  +k  n  (i) 


ni- 1  -fc  1 


m-fc  +  1 


A:! 


<  0  for  n>m>A:>l 


We  form  successive  vectors  d^=b.d\  d'-a  as  follows:  if  d*=(i?,  ■  ■  ■ 
for  k=0,l-l,  then  =  is  formed  from  d*.  by  decreasing  by  one 

a  component  with  index  jd  of  d*'  which  satisfies  'ip>ap  and  increasing  by  one  a 
component  g  of  d*^  which  satisfies  ig<ag,  and  then  rearranging  the  components 
such  that  The  following  relations  hold: 

lid""'  -d*ll  =  f  Kr'-i*  1=2 

;=i 


I  la-d^'-^  11  =  ^  Ittj-'ij  1=  ^  lo-j-'ij-  1-2=1  1  a-d*  1  1-2, 

i=i  j=i 

a  majori  zes  dteM 

majorizes  d*’  majorizes  b. 


and 


(using  22). 

Thus  Br{h)=Br{<f)^Br{d,)^  ’  '  ’  (d^ ) =:^ (a). 

V 


We  will  next  show  that  a  similar  result  holds  for  the  non-replacement 
model. 


Definition:  A  function  of  n  real  variables  is  called  Schur  concave  if  for  every 

Hieorem  (Schur):  If  /  is  a  Schur  concave  function  and  a  majorizes  b  then 

/  (a)^/  (b). 

Proof:  See  for  example  [Marshall  and  Olkin  79], 


A  function  which  is  known  to  be  Schur  concave  is  the  entropy  function  of  a 
probability  distribution. 


Theorem:  Let  a=(ai,  •  •  •  ,aj^)  and  b=(6i,  •  •  •  bj^)  be  two  vectors  satisfying  the 
property  that  Oi’s  and  fej's  are  non  negative  integers  and  when  the  components 
of  a  and  b  are  rearranged  such  that  ai^ci2  •  •  •  and  '  '  ‘  then  a 

majorizes  b.  Let  Brin)  be  the  cost  function  (4),  where  x  is  an  /►/  dimensional 
vector.  Then  £^(a)<i3^(b). 

Proof:  Without  loss  of  generality  we  assume  that  the  given  vectors  a  and  b  are 
such  that  a,>ra2>r  ■  •  •  and  bi>b2^  •  •  •  ^bfj.  The  function 

Bf.{ii.  ■  •  •  —  /'^)  is  Schur  concave  because: 

;  =  1  ^ 


'dBr 

dij 

\  J 


n  71. 


\ 


Thus  if  a  majorizes  b  then  -^(a)  <  i^(b), 

V 

The  following  set  of  corollaries  are  direct  applications  of  the  above 
theorems  to  the  problem  of  estimating  the  number  of  random  block  accesses 
for  retrieving  k  records.  They  apply  to  both  the  non-replacement  and  the 
replacement  model. 

Corollaryl:  Let  a=(ai.  •  •  •  aj^)  and  b=(bi,  •  •  •  bj^)  be  two  vectors  describing  two 
placements  of  the  n  tuples  of  a  relation  in  M  blocks  of  secondary  storage. 
Without  loss  of  generality  '  '  '  —^id  •  '^bf^.  Let  a  and  b  be  such 

that  a  majorizes  b.  Then  the  expected  number  of  blocks  containing  k  distinct 
records  in  placement  a  is  less  or  equal  to  the  expected  number  of  blocks  con- 
tsdning  k  distinct  records  in  placement  b. 

In  the  limiting  case  that  is  possible  to  place  the  records  uniformly  in  the 
blocks  of  the  file,  the  following  corollary  holds. 

Corollary2;  From  all  possible  placements  of  n  records  in  M  blocks  of  secondary 
storage  a  uniform  one  will  result  to  a  maximum  expected  number  of  block 
accesses  for  randomly  retrieving  k  records  from  the  file.  (Uniform  here  means 
that  either  b  or  6  +1  records  are  placed  in  each  block.) 

CoroUaryS;  From  edl  uniform  placements  of  n  records  in  secondary  storage  the 
one  that  utilizes  the  least  number  of  blocks  will  result  to  a  minimum  expected 
number  of  random  block  accesses,  and  vice  versa. 

The  above  theorems  can  also  be  used  to  provide  upper  and  lower  approxi¬ 
mations  of  the  expected  number  of  random  block  accesses  when  the  maximum 
and  minimum  number  of  records  in  blocks  of  the  file  is  known  (in  addition  to 
the  number  of  blocks  and  the  number  of  records  of  the  file).  An  upper 


approximation  will  be  one  that  is  derived  assuming  a  uniform  distribution  of 
the  records  among  the  blocks  of  the  file.  A  lower  approximation  will  be  one 
which  is  derived  by  assuming  a  distribution  which  follows  the  constrains  of  the 
maximum  and  minimum  records  per  block,  and  also  majorizes  any  other  distri¬ 
bution. 

The  following  corollaries  are  applications  of  the  above  theorems  to  the 
problem  of  estimating  the  expected  number  of  distinct  values  remaining  in  an 
attribute  after  a  selection  of  a  subset  of  the  records  of  a  file. 

Corollfiiryd:  Let  a  =  (a,,  •  •  •  .a^j)  and  b=  (bj,  •  •  •  be  two  vectors  describing 
two  distributions  of  n-tuples  over  the  M  distinct  values  of  an  attribute  A. 
Without  loss  of  generality  ai>a2^  •  '  '  ‘  a  and  b  be 

such  that  a  majorizes  b,  and  let  5(a)  and  5(b)  be  the  expected  number  of  dis¬ 
tinct  values  of  A  remaining  after  the  selection  of  k.<n  tuples  (respectively). 
Then  5(a)<5(b). 

Corollaryb:  Let  n  =  (77.j,  •  •  .n^)  be  a  vector  describing  the  distribution  of  the 

attribute  values  of  the  tuples  of  a  relation  on  the  domain  of  values  of  an  attri¬ 
bute  A.  Let  k  tuples  be  randomly  selected  from  the  file.  From  all  possible  dis¬ 
tributions  n  the  uniform  distribution  will  result  to  a  maximum  expected 
number  of  distinct  values  found  in  the  attribute  A  of  the  k  selected  tuples. 

6.  Distributions  of  the  Nunober  of  Blocks  Containing  a  set  of  Records 

In  this  section  we  show  how  to  estimate  the  probability  that  exactly  P 
blocks  contain  a  set  of  k  distinct  records.  A  block  type  is  defined  by  the  number 
of  records  that  exist  in  a  block  at  a  point  in  time.  Let  c  be  the  number  of 
different  block  types  and  n=(ni,  •  •  n^)  with  nj>n2>  •  •  •  >71^,  be  the  type 
characteristic  vector,  where  is  the  number  of  records  in  a  block  of  type  i. 
Let  I=(i  1,  ,lc)  he  the  distribution  of  blocks  of  a  file  over  the  block  types  (e.g. 


there  are  li  blocks  containing  rii  records  each,  ...  Ic  blocks  containing 
records  each),  A  block  selection  vector  i=(ii,  ■  •  ■  ,ic)  has  components  which 
represent  the  number  of  blocks  from  each  block  type  examined  al  a  point  in 
time.  (Component  ij  corresponds  to  the  type  containning  n_,-  records  per 
block.) 

Distributions  for  the  non-replacement  model 

Consider  p  given  blocks  with  distribution  i=(ii,  •  •  •  ,4)  over  the  types  of 
blocks  (|il  =  J  ij  =p).  The  number  of  distinct  ways  that  all  the  p  blocks  are 


retrieved  with  the  selection  of  k  distinct  records  from  the  p  blocks  can  be  com¬ 
puted  recursively  as 


Okij^ij 


with  boundary  condition  for  i=(0,  •  •  •  ,0)  /^(i,n,fc)=0. 

The  probability  that  exactly  p  blocks  are  selected  when  k  records  are 
retrieved  without  replacement  from  all  the  blocks  of  the  file  is 


In  the  special  case  where  there  is  only  one  block  type  (constant  number  of  b 
records  per  block)  we  have:  c=l,  n=(A/)  and  1={M),  where  M  is  the  number  of 
blocks  in  the  file.  Then 


 F(p.b,k)>C« 


with 


F(p.b.k)  =  Ct~^F(p.b.k)C? 


i=0 

This  result  appears  in  [hanger  and  ShumB2], 


Distributions  for  the  rep.acemenl  model 


('onsidcr  /)  ^ivc'n  blocks  with  disl  ribulion  i  =  (i.i.  '  •  >'k)  the  types  of 

blocks  (£  h=p)-  The  number  of  distinct  possible  outcomes  is 
i  =  i 

i=i 


Some  of  these  outcomes  will  be  from  a  proper  subset  of  the  p  blocks.  The 
number  of  possible  outcomes  that  touch  all  p  blocks  is  computed  recursively  as 

F(i.n.k)  =  (i;  71;  7;)‘  -  |;,ko  f(r,n,fc)  fl  c'l 

with  boundary  condition  for  i=(0,0,  •  •  •  0)  F(i,n,A:)  =  0, 

The  probability  that  exactly  p  distinct  blocks  are  selected  when  k  records 
are  retrieved  with  replacement  is 


Qip)  = 


!ij  =p  F{ln.k)  *  f]  ci^ 

 i  =  i  ^ 


n' 


In  the  special  case  of  a  constant  number  of  records  per  block  this  cedcula- 


tion  becomes 


c(p)  = 


F{p.b.k)*C" 


71' 


wth 


,  6  ,  * )  =  (p6  )* ,  6 ,  fc  )  C? 

i=0 


7.  Siimmary 

In  this  paper  we  ha^e  derived  estimates  for  some  important  parameters  in 
data  base  performance  evaluation  when  the  distributions  of  objects  into  buck¬ 
ets  cire  not  uniform.  Parallel  research  activity  in  this  eirea  is  directed  towards 


more  accurate  estimates  of  the  size  of  projections  ([Gelembe  and  CardyBS], 
[Gelemby  and  CardyBS]),  more  accurate  estimates  of  join  sizes  ([Kerschberg  et 
al.BO],  [RosenthalBl]).  more  accurate  estimates  of  record  selectivities  in  the 
presence  of  non-uniformity  and  correlations  of  attribute  values  [Christo- 
doulakisBB],  more  accurate  estimates  of  block  transfers  when  the  probabilities 
of  records  to  be  accessed  are  not  uniform  ([Zahorian  et  al.B3],  [Christo- 
doulakisBl])  and  estimates  of  the  number  of  blocks  containing  a  number  of 
qualifying  records  [hanger  and  ShumB2]. 

We  have  shown  in  this  paper  that  the  assumption  of  uniform  placement  in 
certain  cases  results  to  pessimistic  estimates.  This  result  complements  previ¬ 
ous  results  ([ChristodoulakisBl],  [ChristodoulakisBS])  indicating  that  unifor¬ 
mity  and  independence  of  attribute  values,  as  well  as  uniformity  of  probabilities 
of  records  to  be  accessed  are  also  often  pessimistic  assumptions.  Understand¬ 
ing  the  implications  of  various  assumptions  made  is  an  important  issue  in 
modeling  the  data  base  system  performance. 

Akno’wlQdgeTn2nts :  The  author  would  like  to  thank  C.  Faloutsos  for  careful  read¬ 
ing  of  the  paper  and  useful  suggestions. 
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ABSTRACT 

When  many  users  access  concurrently  the  same  file  batching 
of  queries  is  profitable  because  it  reduces  the  amount  of  work  that 
the  system  has  to  do.  However,  usual  tree  access  mechanisms  are 
not  well  suited  for  batching  queries.  Moreover,  sequential  scan  of 
the  whole  file  may  be  expensive. 

In  this  paper  we  propose  an  alternative  approach.  We  use  an 
access  file  which  is  much  smaller  than  the  file  itself  as  an  access 
mechanism.  The  access  file  is  sequentially  scanned  to  indicate 
the  qualifying  records  of  the  file.  Thus  batching  of  queries 
becomes  easy,  and  since  the  access  file  is  small,  more  profitable 
than  the  sequential  scan  of  the  whole  file  for  a  moderate  number 
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of  queries  in  the  batch. 

We  analyze  the  performance  of  this  file  organization  in  the 
general  case,  and  we  provide  closed  form  formulae  for  the  access 
file  design  when  the  attributes  have  many  distinct  attribute 
values. 

1.  Introduction 

The  increase  of  the  number  of  users  of  DBMS’s  and  the  availability  of 
access  of  remote  information  through  telecommunication  lines  imply  an 
increase  in  the  number  of  users  that  share  common  files.  As  a  consequence,  in 
such  environments  the  number  of  users  that  access  a  common  file  at  one  time 
may  be  large.  In  this  case  batching  of  requests  may  be  profitable  even  for  on 
line  access. 

From  the  systems  point  of  view,  batching  of  requests  is  nearly  always 
profitable  because  it  implies  less  work.  Thus  for  overloaded  sites  batching  of 
requests  may  be  necessity  rather  than  choice.  From  the  on-line  user’s  point  of 
view  batching  of  requests  may  or  may  not  be  desirable  depending  on  its  effect 
on  the  responce  time.  In  order  to  batch  a  number  of  queries  a  certain  waiting 
time  period  before  initiating  the  service  for  a  particular  query  may  be  required. 
On  the  other  hand,  since  the  system  work  required  to  process  a  batch  of  n 
queries  is  less  than  the  time  required  to  process  the  n  queries  individually,  the 
average  responce  time  may  decrease  [Shneidermain  and  Goodman  1976]. 
Another  consequence  of  the  reduced  system  work  is  that  the  utilization  of  dev¬ 
ices  may  drop  and  the  system  throughput,  increase  with  a  net  result  shorter 
responce  times.  This  is  more  realistic  in  high  query  frequency  environments 
where  the  waiting  period  is  short 


Batching  of  requests  is  easier  and  more  profitable  for  sequentially 
accessed  files  than  for  tree  structures,  IVhen  the  levels  of  the  tree  are  many 
the  probability  that  more  than  one  requests  refer  to  the  same  path  is  small  and 
therefore  the  profitability  of  batching  decreases.  Moreover,  updeites  are 
difficult  to  be  batched  in  tree  organizations  [Shneiderman  and  Goodman  1976], 
Batching  becomes  even  harder  for  multi  attribute  queries  because  a  number  of 
tree  structures  may  have  to  be  accessed  and  the  resulting  pointers  to  be 
merged. 

When  the  number  of  queries  that  can  be  batched  is  very  large,  sequential 
scan  of  the  whole  file  is  an  alternative,  possibly  more  profitable  strategy.  How¬ 
ever.  for  on  line  environments  where  the  number  of  batched  requests  cannot  be 
very  large  without  deterioration  of  responce  times,  sequential  scan  of  a  large 
file  may  be  an  expensive  strategy. 

In  this  paper  we  propose  an  alternative  approach.  We  use  an  access  file 
which  is  much  smaller  than  the  file  itself  as  an  access  mechanism.  'Fhe  access 
file  is  sequentially  sceinned  to  provide  pointers  to  the  qualifying  records  of  the 
file.  Thus  batching  of  queries  becomes  easy,  and  since  the  access  file  is  small, 
more  profitable  than  the  sequential  scan  of  the  whole  file  for  a  moderate 
number  of  queries  in  the  batch.  In  section  2  we  describe  the  file  organization 
and  the  access  method.  In  section  3  we  analyse  the  performance  of  this  organi¬ 
zation.  In  section  4  we  discuss  buffering  and  blocking  issues.  In  section  5  we 
present  our  conclusions. 

2.  Access  File  Organization 

Given  a  file  F  we  associate  an  access  mechanism  with  it  which  we  hen¬ 
ceforth  call  access  file.  An  access  file  A  is  composed  of  access  file  rectyrds 
which  correspond  (one  to  one)  to  records  of  file  F.  Access  file  records  consist  of 
access  file  fields  which  correspond  (one  to  one)  to  the  attributes  of  F.  Access 


file  fields  have  field  values  representing  the  attribute  values  of  the  attributes  of 
F.  Field  values  are  aJbstractin'ns  of  the  attribute  values  of  F.  To  obtain  the  field 
value  V  which  corresponds  to  an  attribute  value  V  of  an  attribute  i,  a  hashing 
function  7i  is  used.  Thus  v  =  Ti(V). 

Consider  a  multiattribute  query  ^  on  a  file  F.  Let  Q(ii,  ■  -  im)  be  a 
boolean  expression  on  the  attributes  ii  •  ■  ■  im  of  F.  representing  the  query  Q. 
The  boolean  expression  Q{ii.  ■  ’  ■  im)  is  mapped  on  a  boolean  expression 
QA{i'i>  ■  ’  ’ '^'m)  on  the  access  file  fields  i'l,  ■  ■  ■  which  correspond  to 
ii.  '  im.  applying  the  transformations  7^^,  •  •  •  7"^  for  mapping  the  attribute 

values  into  field  values,  and  leaving  the  boolean  operators  as  they  are. 

To  retrieve  the  records  of  F  that  qualify  in  a  query  Q  with  a  boolean 
expression  ^(ii,  •  •  •  im),  the  boolean  expression  QA{i'i.  ■  ■  •  i'm),  is  obtained 
first.  Then  the  access  file  A  is  sequentially  scanned  to  identify  the  access  file 
records  that  qualify  in  QA{i'  i,  •  '  •  i'm)-  f’or  each  access  file  record  qualifying 
the  corresponding  record  of  F  is  retrieved.  It  is  clear  from  the  above  descrip¬ 
tion  that  the  set  of  records  of  F  retrieved  from  a  boolean  expression 
^(ii.  ■  ■  ■  ■im)  is  a  superset  of  the  records  of  F  actually  qualifying  in  Thus 
retrieved  records  of  F  are  examined  for  qualification  before  they  are  returned 
to  the  user. 

Batches  of  queries  are  processed  in  the  same  manner.  For  each  query  Q  in 
the  batch  with  a  boolean  expression  •  •  im),  boolean  expression 

^A(i' 1,  ’  '  '  i'm)  oEt  file  access  file  is  found  first  using  the  transformations 
Then  the  access  file  is  sequentially  examined  to  identify  all  access 

file  records  qualifying  in  at  least  one  of  the  boolean  expressions  QA(i'i,  '  '  ’  i'm) 
in  the  batch.  The  records  of  F  that  correspond  to  these  records  of  the  access 
file  are  retrieved  only  once.  If  one  record  qualifies  in  more  than  one  queries  in 
the  batch  duplicates  of  the  record  are  produced  and  returned  to  the  users. 


As  can  be  seen  from  the  above  description  batching  of  requests  in  this 
orgaaiization  is  easy  due  to  the  sequential  way  of  accessing  both  the  access  file 
and  the  file  itself.  Tlie  profitability  of  batching  from  the  systems  point  of  view 
comes  from  the  fact  that  for  each  batch  of  queries  the  access  file  A  is  scanned 
only  once  (and  therefore  the  cost  per  query  is  reduced),  as  well  as  from  the  fact 
that  blocks  of  secondary  storage  containing  records  of  the  file  F  which  queilify 
in  more  than  one  queries  in  the  batch  are  retrieved  only  once.  Within  the 
batch  single  attribute  queries  involving  one  or  more  attribute  values  of  the 
same  attribute  as  well  as  complex  multiattribute  queries  can  be  treated  easily 
and  uniformly. 

Batching  updates  is  also  handled  easily  in  this  organization.  If  the  update 
is  a  change  of  the  value  of  an  attribute  i  of  a  record  j  of  F,  the  function  7*  is 
used  to  find  the  new  value  of  the  access  file  field  i'  which  corresponds  to  i.  The 
new  value  is  recorded  in  the  access  file  when  the  corresponding  access  file 
record  is  examined.  Deletions  of  records  of  F  are  easily  handled  by  deleting  the 
corresponding  access  file  record.  Insertions  within  F  can  be  handled  by  having 
a  percentage  of  free  space  within  the  blocks  of  the  access  file,  such  that  inser¬ 
tions  do  not  require  the  rewriting  of  more  than  one  or  two  blocks  of  the  access 
file  on  average. 

3.  Performance  Analysis 

It  is  important  that  the  superset  of  records  of  F  retrieved  is  tight.  This  can 
be  achieved  if  a  large  number  of  bits  is  used  for  each  field  of  the  access  file. 
Large  number  of  bits  per  field  however  increases  the  cost  of  scanning  the 
access  file.  Thus  there  is  a  tradeoff  involved  in  the  choice  of  the  optimal 
number  of  bits  1^  of  the  attribute  i. 

Let  Qi^  Q2.  '  '  Qt  be  query  types  involving  at  least  one  attribute  of  F, 
Pi,Pz  ■  ■  Pt  be  the  probabilities  with  which  these  query  types  are  used  in  user 


queries  =  0.  sJid  tt  be  the  probability  of  a  query  specifying  no  attributes 

i 

(e.g.  with  probability  1  -  tt  a  query  belongs  to  one  of  the  query  types 
Cl.  ■  «).  Each  query  type  is  characterized  by  the  attributes  that  a  query  Q 
involves  and  the  boolean  operators  interconnecting  them  [Hammer  and  Chan 
76].  For  example  if  all  queries  are  conjunctive,  a  query  type  involves  all 
queries  which  refer  the  same  attributes. 

Consider  a  batch  of  b  queries.  With  probability  (1— (l— tt)**)  at  least  one  of 
the  queries  specifies  a  sequential  scan  of  the  file.  In  this  case  the  access  file 
need  not  be  touched.  All  queries  in  the  batch  vrill  be  answered  by  scanning  the 
file  F,  with  an  expected  cost  where  BL  is  the  number  of 

blocks  in  the  file  F,  and  SF  is  the  cost  of  one  block  access  of  the  file  F  when  all 
the  blocks  of  file  F  are  sequentially  accessed. 

With  probability  (1— rr)*’  no  query  in  the  batch  specifies  a  sequential  scan  of 
the  file  F.  In  this  case  the  access  file  A  has  to  be  sequentially  scanned  with  an 
expected  cost 

tk 

where  S4  is  the  cost  of  accessing  one  block  of  the  access  file.  In  this  formula 
is  the  number  of  bits  per  field  of  the  access  file,  v  is  the  number  of  attributes, 
BPB  is  the  number  of  bits  per  block  of  the  access  file  used,  and  N  is  the  number 
of  records  of  the  file  F. 

The  records  of  file  F  that  correspond  to  the  selected  records  of  the  access 
file  have  also  to  be  retrieved.  The  number  of  records  of  the  file  F  that  will  be 
retrieved  depends  on  the  number  of  bits  per  field.  Assuming  a  good  hashing 
function,  the  proportion  of  records  of  /‘’retrieved  from  a  single  attribute  query 
(record  selectivity)  is  given  by 


SlLpiQ^)  = 


1 


where  Q  =  This  formula  is  derived  by  observing  Lhat  the  Di  distinct  values 
are  mapped  with  the  hashing  function  randomly  in  the  set  of  Q  possible  values 
represented  by  the  li  bits.  The  number  of  records  of  F  retrieved  by  more  com¬ 
plicated  queries  involving  conjunctions  and  disjunctions  of  attribute  values  can 
be  found  by  using  the  independence  of  the  selected  field  values  assumption. 


The  expected  cost  for  retrieving  the  records  of  F  indicated  is 


CT*il-7T)^  *  2 


b' 


Tiling!  •  •  rq! 


where  CT  is  the  cost  of  accessing  one  block  of  the  file  F.  SA  and  CT  can  be  con¬ 
siderably  different.  Some  reasons  are:  (l)  The  two  files  may  be  stored  in 
different  devices  in  order  to  avoid  rcxndom  moves  of  the  access  mechanism.  (2) 
The  logical  block  sizes  may  be  different,  and  (3)  All  the  blocks  of  the  access  file 
are  retrieved  and  thus  their  access  is  facilitated  by  prefetching. 
|5i  I  =  kiSup{Q^)  is  the  record  selectivity  of  all  queries  of  type  ^  in  the  batch. 
(There  are  t  types  of  queries.)  Here  is  the  expected  number  of  distinct 
queries  of  the  same  query  type  specified  in  the  batch  and  it  is  estimated  as 


I 

where  is  the  number  of  queries  of  type  Q,  specified  (Tij^O,  =6),  and  A 

i=l 

is  the  domain  of  possible  values  of  In  the  above  formula 

luAi  = 

i  =  1  i=l 

is  the  record  selectivity  of  all  the  queries  in  the  batch  when  the  access  file  is 
used.  In  this  cost  expression  the  function  Blocks  is  used  to  estimate  the 
number  of  blocks  of  the  file  F  containing  the  estimated  number  of  records 
[Christodoulakis  32 J. 


Therefore  the  expected  system  cost  for  b  queries  batched  is  given  by 


V 

C  =  a4W*5|^'(l-7T)''+5™i»(l-(l-;r)‘’)+  (1) 

nru 

cT»(i-jv)'’'  H  •  if‘»aocA:s(yv»|  u^l) 

i  =  l 

The  optimal  system  cost  can  be  found  by  minimizing  the  cost  expression  with 
respect  to  f/s.  For  small  number  of  query  types  and  attributes  involved,  the 
optimal  li's  can  be  found  by  using  integer  programming  techniques.  Next,  we 
will  examine  two  special  cases. 


SS/ngle  M tribute 

For  single  attribute  of  importance  in  the  file  the  cost  equation  becomes: 


artf 

k 

+  CT*'(1-T7)*  *Blocks{N* - ^ ^ - ) 


withfci  =  Di 


and  Ci 


(2) 


Figure  1  shows  the  optimal  li  for  various  values  of  A  various  batching 
factors.  As  the  figure  indicates,  larger  number  of  distinct  attribute  values 
imply  larger  optimed  number  of  bits.  However,  the  increase  is  not  proportional 
to  the  increase  of  the  distinct  attribute  values.  This  is  due  to  the  fact  that  for 
small  number  of  attribute  values  hashing  of  two  distinct  attribute  values  in  the 
same  field  value  is  costly.  Thus  a  (proportionally)  larger  number  of  bits  is 
required  in  order  to  make  sure  that  collisions  are  not  frequent.  On  the  other 
hand,  for  large  number  of  distinct  attribute  values  the  cost  of  collisions  is  not 
much.  The  case  of  the  large  number  of  attribute  values  is  the  more  interesting 
one  for  single  attributes.  Another  observation  from  figure  1  is  that  the  increase 
in  the  number  of  queries  batched  implies  an  increase  in  the  optimal  number  of 


bits  of  a  field,  mainly  because  the  cost  of  scanning  the  access  file  is  shared 
among  all  queries  in  the  batch. 

Figure  2  shows  the  cost  per  query  for  various  numbers  of  queries  in  the 
batch.  The  cost  decreases  faster  for  attributes  with  smaller  number  of  attri¬ 
bute  values.  This  is  due  to  the  fact  that  the  probability  that  the  same  query  is 
encountered  in  the  batch  more  thaji.  once  is  higher.  Figure  3  indicates  that  the 
drop  in  the  cost  is  even  faster  for  a  larger  blocking  factor  in  F.  The  reason  is 
that  for  relatively  small  number  of  distinct  attribute  values  several  of  the  qual¬ 
ifying  records  may  be  found  in  the  same  block.  This  is  unlike  for  large  number 
of  attribute  values.  Finally  Figure  4  compares  the  cost  of  using  the  access  file 
organization  versus  the  cost  of  sequentially  scanning  the  file  F.  For  small 
number  of  attribute  values  and  large  number  of  queries  in  the  batch  sequential 
scan  of  the  file  itself  may  be  more  profitable  and  vice  versa.  The  savings  by 
using  the  access  file  organization  instead  of  sequentially  scanning  the  file  is 
large  for  large  number  of  attribute  values. 

A  closed  form  formula  for  the  number  of  bits  per  field  can  be  found  for 
attributes  vrith  a  large  number  of  attribute  values  by  approximating  the  cost 
formula  (2)  with: 


C  =  -h  SF*BL*{l-{l-n)^)  CTn)*2  *N 


Differentiating  we  obtain: 


In  Table  1  we  compare  values  obtained  using  the  approximate  formula  with 
the  optimal  values  obtained  by  (2).  In  this  table,  b  is  the  number  of  queries 
batched,  Appr  is  the  value  of  It  using  (3),  F  is  the  blocking  factor  in  the  file,  Di 
is  160CX)  distinct  values,  is  32000  distinct  values,  Dz  is  64000  distinct  values. 
In  this  experiment  SA  -  CT  and  BPB  =  4096  was  used.  The  approximation  is 


very  good  for  all  tests. 
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15 

15 

15 

15 

Qmjurtctive  Multiattribute  Retrieval  with  Attributes  IhdependendLy  Specified  in 
Queries 

Several  multiattribute  retrieval  access  methods  have  been  proposed  in  the 
literature  ([Nievergelt  et  al  81],  [Gueting  and  Kriegel  80],  [Scheuerman  and 
Ouksel  80],  [Aho  and  Ullman  79],  [Anderson  and  Berra  77],  [Hammer  and  Chan 
76],  [Bentley  75],  [Schkolnick  75],  [Rothnie  and  Lozano  74],  [Stonebraker  74], 
[Lum  70]).  The  assumption  that  attributes  are  independently  specified  in 
queries  has  been  used  in  some  of  them  to  obtain  closed  form  formulae  for  the 
optimal  design.  Cost  formula  (1)  can  be  simplified  in  a  conjunctive  multiattri¬ 
bute  retrieval  environment  where  attributes  are  independendly  specified  in 
queries. 

Let  Pi  be  the  probability  that  attribute  i  appears  in  a  query.  The  probabil¬ 
ity  that  all  attributes  of  the  nonempty  subset  Vq  of  the  set  of  attributes  V  of  the 
file  are  specified  in  a  query  (and  only  those)  is 

n(Pi)'^  n  (i-Pi) 

icY-Vq 

n  n  (Pi)*'  n  (i-Pi)+7T  =  1 

icV-Vq 


such  that 


where  tt  =  }  1(1— Pi)  is  Iho  probability  of  a  query  specif3ring  no  attributes. 

icK 

The  average  record  selectivity  for  a  single  multiattribute  query  when  at 
least  one  attribute  is  specified  is 

*^1  =  S[ n(Px)^  n  (i-pi)*n( - - — 

with  Q  =  2*‘.  In  a  batch  of  b  distinct  queries  the  average  record  selectivity  can 
be  approximated  by: 


5,  =b*S-{l-S,)^ 

The  average  cost  therefore  is 

C  =  +  SF*(SZ,*(1-(1-7v)‘))+CT*(1-it)’’ 'aoc/ts(Af*5i)  (4) 

tjrJj 

When  the  number  of  attribute  values  is  large  the  cost  formula  (4)  can  be 
further  simplified.  A  similar  derivation  with  the  one  that  follows  was  used  in 
[Aho  and  Ullman  79]  for  the  optimal  file  design  in  multiattribute  hashing 
environments. 

For  attributes  with  large  number  of  distinct  attribute  values  (2)  becomes: 

E'. 

nrtS 

C7*(i-7r)'"';v<6'2 [n(Pi)'  n  (1-Pi)'  n  (^)] 

VqcV  icVq  UV-Yq  UV-Vq  ^ 

Or 

El. 

C  =  5/1*A"-;^-'(I-7r)''i-5P*(Z7L*(l-(l-7r)’’))i- 
Drti 

CT*{l-nf  n 

^  Pi 
Or 

E'i 

C  =  SA'N»-~*(\-nf  +SF’(BL’CL-(\-nf)^ 

Ijrtj 

CT*{l-TTf  *N*b 

t=i  1-^t 


Differentiating  we  obtain: 


dk  BPB  ^  ^ 


PL_4^2  k 


14._^*2-  ‘i  ;=i  ^  Pi 

1-Pi 


0 


Dividing  pairwise  we  obtain  that 


\-Pi 


l+-^^2  *i 


1-Pi 


-p~*Z 

1-Pj 

^-Pj 


for  every  i  and  j .  Thus 


P^  *g  —  ^Pj. _ *2  h 

l-j>i  1-pj 

for  every  i  and  j .  Substituting 


SA*N 

BPB 

Thus 


il-^)^-CT^*n*{l-ny  *Nnog{2)*^r^*^  =  0 

^  1-Pi  1-Pi 


2  *(1+73^2“^) 

I-Pi 


SA*N 

BPB 


^(l-7r)< 


=  Ci 


CT*b  *ix*{l-ny  *N*iog{2)  V 

1-Pi 

where  Q  is  a  constant  which  depends  on  attribute  i  only.  The  number  of  bits  li 
for  attribute  i  can  therefore  be  found  directly  from  this  formula  by  examining 
a  range  of  possible  values  for  (say  from  0  to  20).  However,  since  2~^  is  usu¬ 
ally  a  small  quantity,  for  reasonable  values  of  Pi  and  v  (such  that 
Pi  ~l 

■r— —  *2  *  ♦(w-l)  «  1)  a  closed  form  formula  can  be  obtained.  We  have 

1-Pi 


i-Pi  1-pi 


fVom  which 


'-i  = 


log  {2) 


nog{ 


2*Pi*{v-\) 


(5) 


CfBPBt  *7r 


iT-l) 


Table  2  compares  the  results  obtained  using  (4)  with  results  obtained  using  the 
closed  form  formula  (5)  for  attributes  with  large  number  of  attribute  values.  In 
the  table  P  is  the  probability  of  reference  of  every  attribute.  The  approxima¬ 
tion  is  satisfactory  for  all  tests. 
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Figure  (4)  shows  that  the  number  of  bits  increases  as  the  probability  of 
reference  of  one  of  the  attributes  in  queries  increases.  In  this  figure  the  proba¬ 
bility  of  reference  of  each  of  the  other  attributes  was  constant  throughout  the 
experiment.  The  figure  also  shows  (for  the  case  of  the  two  attributes)  that 
although  the  probability  of  reference  of  the  second  attribute  was  constant,  the 
number  of  bits  for  this  attribute  decreases  as  the  probability  of  reference  of  the 
other  attribute  increases.  The  reason  is  that  as  the  probability  of  reference  of 


the  first  attribute  increases,  the  probability  that  the  second  attribute  appears 
alone  in  a  query  decreases. 

Figure  5  shows  how  the  number  of  bits  per  field  depends  on  the  number  of 
attributes  specified  in  multi  attribute  queries.  In  this  experiment  the  probabili¬ 
ties  of  reference  of  all  the  attributes  in  the  file  increased.  Due  to  the  indepen¬ 
dence  assumption  this  implies  that  as  the  probability  increases  more  and  more 
attributes  appear  on  average  in  a  query.  As  the  figure  shows  the  number  of 
bits  per  attribute  reduces  for  large  probabilities  since  bits  from  a  number  of 
fields  contribute  into  resolving  the  query. 

4.  BufferlDg  and  Hocking 

The  cost  equations  of  the  previous  section  imply  that  all  the  access  file  is 
brought  from  the  secondary  memory  into  the  primary  memory.  This  would  be 
the  case  for  example  in  an  environment  where  the  queries  would  be  concen¬ 
trated  for  a  time  period  and  then  executed  as  a  batch.  In  such  an  environment 
is  not  profitable  to  permanently  maintain  part  of  the  access  file  within  the  main 
memory. 

Access  files  however  can  be  useful  in  very  active  environments  also.  In 
these  environments  the  system  can  make  particularly  good  use  of  an  available, 
large,  main  memory  resident  buffer  space.  The  reason  is  that  all  the  buffer 
resident  portion  of  the  access  file  can  be  utilized  before  any  replacement  takes 
place.  This  is  due  to  the  fact  that  all  the  access  file  is  used  for  the  query 
evaluation.  KTThen  access  files  are  used  as  access  mechanisms  the  block  size 
can  be  chosen  to  be  large.  This  will  result  to  reduced  queueing,  seek,  and  rota¬ 
tional  delay  times  associated  with  each  block  access.  A  good  choice  of  the  logi¬ 
cal  block  size  for  the  access  file  will  be  the  size  of  the  buffer  space  allocated  for 
the  access  file. 


Next,  we  discuss  the  choice  of  the  pairameters  of  the  access  file  when  a  por¬ 
tion  of  the  access  file  is  main  memory  resident  Let  B  bits  of  main  memory  be 
allocated  for  buffer  ing  the  access  file  only.  'Ihe  query  evaluation  process  starts 
by  first  examining  the  contents  of  the  buffer  space,  and  then  it  proceeds  to  the 
other  blocks  of  the  access  file  sequentially.  For  the  conjunctive  multi  attribute 
retrieval  environment  with  attributes  independendly  specified  in  queries  which 
was  described  in  the  previous  section,  the  cost  can  be  expressed  as 

C"  =  C,  =  +  ^Blocks  {N*St,) 

if  I^Li<B  and 

i 

c*  =  Cz  =  SA*{N*Y,L^-B)^SF*'{BL^{l-{l-7T)^))^CT*{l-n)^  *BLocks  {N*St,) 

i 

if  P/^Li>B  (in  analogy  to  (4)). 

i 

To  find  the  Li's  which  minimize  C*  we  observe  the  following: 

1)  Cl  is  decreasing  function  of  li's  and  therefore  it  obtains  its  minimum  at  the 

boundary  -  B). 

i=l 

2) Let  =  ■■■  •  ,v  be  the  optimal  choice  of  li's  for  the  unconstrained  function 
Cg.  Then  Li,i  =  \,v  minimizes  the  cost  function  C  given  by  (4)  edso  (and  vice 
versa)  because  C  and  Cg  have  the  same  partial  derivatives. 

3) ]f  the  above  solution  is  in  the  feasible  region  of  Cg  [N^li^  B)  then  is  the 

i  =  l 

globally  optimal  solution  (minimize  J*)  because 

=  =  \Nt  k=B) 

i=l  i=l 

=  C\{k,i  =  \.v\Nf,li=B) 

i  =  l 

i  =  l 


The  above  suggest  the  following  algorithm  for  choosing  the  li's: 


t=l  1=1 


a).  Find  It.  i=l.v  using  (5),  and  compute  If  B  then  i  =  l,v  is 

the  desired  solution. 


V 


b)  If  NY^li<B  then  the  it's  can  be  found  from  C'l  for  =  B.  The  method  of 

i=l  »=» 


Lagrange  multipliers  can  be  used; 


Ci  =  {CT)*NbTT 


1=1  ^  Bt 


-1 


Differentiating; 


-\N-{ CT)Nb  7t(  1  -77)*’  log  (2) 


1-pi 


1-pi 


II 

fj 

1+  — -  - 

-2 

J=1 

^-Pj 

=0 


The  solution  of  this  system  of  v  non-linear  equations  with  v  unknowns  can  be 
derived  as  in  the  previous  section.  Thus: 


lag(Z) 


2*Pi 


( 1  -p- )  »( -V  /  -  -  - 1) 

U  P^)  iV  b*7T*{CT)*(l-TT)^  ^ 


where  li  satisfies: 


Nf,k=B. 
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We  can  rewrite  this  as 
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Solution  (6)  is  useful  when  a  large  buffer  space  is  available.  In  this  case  the 


access  file  parameters  can  be  chosen  such  that  the  access  file  completely  util¬ 
izes  the  buffer  space.  The  above  solution  (6)  implies  that: 


1.  Each  field  is  originally  allocated  an  amount  --  of  buffer  space. 


Pi 

2.  The  length  of  a  field  i  is  increased  if  the  value  of  log2:j - is  greater  than 

1  —pi 

Pi 

the  average  of  log2  versa. 

3.  The  size  is  B. 


5.  Summary-Conclusions 

Batching  of  user  requests  can  be  important  both  from  the  system’s  and  the 
user's  point  of  view.  In  this  paper  we  have  presented  an  access  mechanism 
which  facilitates  batching  of  queries  in  large  information  systems.  In  environ¬ 
ments  where  the  user  queries  request  overlapping  data  the  savings  of  batching 
will  come  not  only  from  the  fact  that  queries  in  a  batch  share  the  cost  of  using 
the  access  mechanism,  but  also  from  the  fact  that  the  total  number  of  records 
retrieved  is  smaller  than  the  sum  of  records  qualifying  in  each  query. 

The  scheme  proposed  exploids  very  well  the  existence  of  a  large  available 
buffer  in  mam  memory.  The  contents  of  the  buffer  can  be  completely  utilized 
before  any  replacement  takes  place.  Thus  large  block  sizes  Ccin  be  used  in 
order  to  reduce  the  overheads  associated  with  block  accesses.  Finally,  when  a 


very  large  main  memory  buffer  is  available,  the  size  of  the  access  file  can  be 
chosen  to  completely  utilize  this  space. 

Access  files  have  an  additional  advandage  in  a  distributed  environment: 
They  can  be  distributed  to  satellites  in  order  to  offload  a  busy  central  site.  A 
differential  file  in  the  central  site  can  be  used  to  store  updates  in  order  to 
reduce  communication  overheads.  The  batch  of  queries  will  be  examined 
versus  the  access  mechanism  which  is  stored  in  a  satellite  as  well  as  versus  the 
differential  file  in  order  to  retrieve  the  qualifying  records.  The  much  smaller 
storage  requirements  of  access  files  in  comparison  to  indexing  schemes  allow 
for  the  duplication  of  the  access  mechanism  in  more  than  one  satellite,  thus 
avoiding  system  bottlenecks. 

Access  files  are  useful  access  mechanisms  for  non-formatted  attributes  as 
well  [Tsichritzis  and  Christodoulakis  83].  Searching  for  a  pattern  within  the 
access  file  can  be  reduced  to  a  problem  of  recognition  for  finite  automata  [Tsi¬ 
chritzis  and  Christodoulakis  83].  Since  queries  in  a  batch  can  be  seen  as  regu¬ 
lar  expressions  of  a  special  form  (disjunctive)  some  optimizations  are  also  pos¬ 
sible  [Aho  et  al.74].  The  whole  technique  can  be  cast  in  VLSI. 

There  have  been  many  other  multiattribute  retrieval  schemes  proposed  in 
the  literature  and  a  detailed  comparison  with  those  schemes  seems  very 
difficult.  We  will  limit  ourselves  to  general  advandages  and  dis advandage s. 

In  comparison  to  various  indexing  schemes  access  files  seem  to  have 
advandages  in  the  amount  of  storage  that  require,  and  the  good  batching  pro¬ 
perties.  They  will  also  have  an  advandage  in  files  with  many  attributes  when 
some  queries  specify  a  large  number  of  attributes,  as  well  as  in  environments 
with  a  large  insertion  deletion  activity.  Indexing  schemes  will  be  more  advan- 
dageous  in  environments  with  a  small  update  to  query  ratio,  when  a  small 
number  of  attributes  is  specified  in  queries. 


In  comparison  to  various  multiattribute  hashing  schemes  this  method 
seem  to  be  more  suitable  for  dynamic  environments  with  large  variations  in  file 
sizes  and  user  access  patterns.  Access  files  can  behave  well  in  environments 
where  a  mix  of  single  attribute  and  raultiattribute  queries  is  asked  by  the  users 
because  there  are  not  restrictions  on  the  number  of  bits  allocated  for  each 
attribute  (in  contrast  in  multiattribute  hashing  the  sum  of  bits  of  the  hashing 
function  is  constant.)  Finally,  access  files  allow  that  the  file  is  organized 
according  to  a  primary  attribute  (or  attributes)  if  desired.  This  will  facilitate 
frequent  ordered  output  or  range  queries  on  this  attribute.  Both  methods  can 
work  in  an  environment  with  range  queries  if  order  preserving  transformations 
are  used. 
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Engineering  Council  of  Canada  under  the  Strategic  Grant  G0668. 
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Figure  1 

Optimal  number  of  bits  as  function  of  the  distinct  values  of 
an  attribute 
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Figure  2 

Cost  per  query  for  various  numbers  of  queries  in  the  batch. 
Blocking  factor  in  the  file  is  1. 


Figure  3 

Cost  per  query  for  various  numbers  of  queries  in  the  batch. 
Blocking  facgor  in  the  file  is  5. 
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Figure  4 

Relative  cost  of  accessing  the  qualifying  records  by  using  the 
access  file,  versus  using  sequential  scan  of  the  file  itself. 
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Figure  5 

B+  tree  storage  requirements  without  lowest  level  storage  requirements. 
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Figure  6 

Optimal  number  of  bits  for  an  attribute  as  function  of  the  frequency 
of  reference  of  the  attribute  in  queries.  The  probabilities  of 
reference  of  the  other  attributes  remain  constant. 
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Figure  7 

Optimal  number  of  bits  per  attribute  as  function  of  the  probability 
of  reference  of  every  attribute. 


MESSAGE  ADDRESSING  SCHEMES 


D.  Tsichritzis 

Computer  Systems  Research  Group 
University  of  Toronto 


1.  Introducticxi 

One  of  the  most  important  problems  in  electronic  mail  systems  is  the 
specification  of  names  and  addresses  in  the  messages  [Schicker  82,  Shoch  76]. 
In  many  current  message  systems  this  problem  is  addressed  in  a  particular 
manner  [Birrell  82].  However,  it  is  important  to  abstract  the  problem  and  to 
deal  with  it  independently  and  without  any  consideration  of  the  physical  rout¬ 
ing  of  the  messages. 

Consider  a  message  system  consisting  of  messages,  addresses,  persons 
receiving  messages  and  stations  routing  the  messages.  An  addressing  scheme 
is  a  way  of  specifying  and  interpreting  Information  on  the  messages  which 
finally  brings  them  to  the  attention  of  the  proper  recipients.  With  this  paper  we 
will  attempt  to  identify  addressing  schemes  and  investigate  their  properties. 

To  illustrate  the  differences  in  addressing  schemes  consider  three 
different  paradigms.  As  a  first  example  consider  the  manner  that  letters  are 
addressed  in  regular  post  office  mail.  The  addressing  scheme  assumes  the 
existence  of  a  hierarchical  structure  of  mail  stations  and  addresses  (country, 
state,  city,  street.  No).  The  recipient’s  name  is  specified  as  additional  informa¬ 
tion  to  verify  the  correct  delivery  of  the  mail.  The  letter  is  routed  by  interpret¬ 
ing  the  address  from  the  top  of  the  hierarchy  down,  i.e.,  country,  state,  city, 
street.  No.  This  is  an  example  of  an  addressing  scheme  which  relies  on  the  user 
description  of  the  routing  of  the  message.  The  actual  physical  routing  may  be 
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different  but  the  specification  of  the  address  provides  at  least  a  hypothetical 
routing  procedure. 

As  a  second  example  consider  the  addressing  scheme  used  in  telex  mes¬ 
sages.  Each  address  has  a  unique  name.  A  user  sending  mail  specifies  the 
address(es)  to  which  the  mail  should  go.  There  is  no  information  about  the 
routing  as  part  of  the  address  specification.  The  system  chooses  the  most 
appropriate  routing  for  the  message  on  the  basis  of  the  unique  id’s  of  the  reci¬ 
pients. 

As  a  third  example  consider  the  way  that  a  message  is  delivered  by  word  of 
mouth  in  a  village.  Suppose  the  message  is  "Peter’s  cousin  has  arrived".  The 
message  is  actually  passed  on  as  "Spread  the  word  until  it  reaches  Peter  that 
his  cousin  arrived".  The  message  takes  many  alternate  paths.  Each  person 
makes  intelligent  choices  in  order  to  route  the  message.  When  the  messeige  is 
received  it  generates  the  counter  message  "He  knows".  The  spreading  of  the 
counter  message  eventually  stops  the  unnecessary  transmission  of  the  original 
message. 

It  is  interesting  to  compare  these  three  message  addressing  schemes  and 
draw  some  conclusions  about  their  properties.  The  first,  post  office  addressing 
scheme,  makes  many  assumptions  about  the  routing  of  the  messages.  If  the 
structure  of  the  stations  changes,  for  example,  two  mail  stations  merge,  the 
logical  routing  present  in  the  address  should  be  mapped  into  a  new  physical 
routing.  If  some  level  of  the  hierarchy  is  omitted,  for  example,  the  state  is  not 
mentioned,  then  theoretically  there  is  no  way  of  binding  uniquely  the  city  to 
the  country.  The  regular  mail  has.  of  course,  much  more  resiliency  because  it 
relies  heavily  on  the  collective  experience  of  the  people  employed  in  the  mail 
stations,  i.e.,  memory  in  the  addresses.  However,  the  formal  definition  of  a 
hierarchical  addressing  scheme  does  not  incorporate  such  intelligence, 
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Another  drawback  of  this  addressing  scheme  is  its  difficulty  in  handling  excep¬ 
tions.  An  error  in  the  address  is  discovered  only  when  the  mail  cannot  be 
routed  or  delivered.  There  is  no  way  cf  informing  immediately  the  sender  that 
an  error  has  been  made.  Finally,  it  is  tedious  to  specify  groups  of  addresses 
other  than  the  groups  inherent  in  the  ’ev-els  of  the  hierarchy. 

The  second,  telex  addressing,  scheme  relies  heavily  on  the  sender  knowing 
the  exact  name  of  each  recipient.  No  I'outing  information  is  specified.  A  simple 
error  in  the  address  will  result  on  an  illegal  address.  This  situation  can  be 
detected  immediately  if  a  list  of  valid  addresses  is  available.  If  an  address  is 
specified  other  than  the  correct  one  the  system  will  simply  deliver  the  message 
to  the  "wrong"  address.  There  is  no  redundancy  in  the  addressing  scheme  to 
catch  that  error. 

Both  of  the  previous  addressing  schemes  have  limitations.  First,  the  con¬ 
tents  of  the  message  are  not  considered  as  part  of  the  addressing  scheme. 
Inforaiation  in  the  message,  which  may  be  appropriate  for  addressing  it  prop¬ 
erly.  is  not  utilized.  The  destination(s)  is  determined  a  priori  and  is  specified 
separately  from  the  contents  of  the  message.  Second,  the  binding  of  addresses 
to  recipients  is  strict  and  static.  As  a  result,  a  "change  of  address"  of  the  reci¬ 
pient  is  poorly  hemdled.  Notice  that  "change  of  address"  does  not  mean  a 
change  of  the  address  name  or  routing.  It  means  that  the  recipient  gets  assosi- 
ated  with  a  different  address.  In  both  addressing  schemes  this  situation  will  be 
handled  either  by  leaving  a  forwarding  address  to  reroute  the  message,  or  by 
notifying  the  potential  senders  of  the  new  address.  Third,  intelligence  about 
the  routing  environment  does  not  enter  in  the  addressing  schemes.  The  rout¬ 
ing  stations  follow  very  strict  rules  ccncerning  the  handling  of  messages.  As  a 
result,  special  conditions  cannot  be  ce.alt  with  and  result  in  undelivered  mes¬ 
sages.  Finally,  the  recipients  are  specified  only  by  the  sender  of  the  message. 
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There  is  no  mechanism  for  interpreting  the  message  contents  by  the  routing 
stations  in  order  to  deliver  the  message  to  more  recipients.  The  recipients 
have  also  no  means  of  specifying  what  messeiges  they  would  like  to  see. 

Contrast  the  above  situation  with  the  third,  villeige  broadcast,  addressing 
scheme.  In  this  case  we  do  not  specify  an  address.  We  specify  a  recipient  as  an 
integral  part  of  the  message.  The  message  is  interpreted  and  routed  according 
to  the  information  contained  in  the  message  and  available  in  each  routing  sta¬ 
tion.  The  message  actively  hunts  down  the  recipient  as  opposed  to  being 
delivered  to  a  static  mail  box.  A  "change  of  address"  is  handled  very  smoothly 
since  the  binding  of  recipients  to  addresses  is  not  static. 

In  this  section  we  argued  that  addressing  schemes  for  messages  can  be 
very  different  and  they  can  have  widely  different  properties.  To  identify  the 
differences  clearly  we  need  a  model  for  addressing  schemes. 

2.  A  model  for  addressing  schemes 

The  m6iin  objects  of  ein  addressing  scheme  are  messages  and  addresses. 
Messages  eire  uniquely  identified  and  they  belong  to  a  generator  set  of  messages 
|m|.  Addresses  are  also  uniquely  identified  and  they  are  nodes  of  a  directed 
graph,  which  defines  their  connectivity.  An  address  a  has  an  edge  to  another 
address  6  if  a  can  send  mail  to  6 .  The  word  "aadress"  is  used  with  many  mean¬ 
ings  in  mail  systems.  It  may  mean  a  physical  address,  a  logical  address  or  a 
role  that  a  person  plays.  It  may  also  mean  the  specification  which  can  be  inter¬ 
preted  into  any  notion  of  address.  Addresses  in  our  model  are  nodes  of  control 
where  messages  can  be  deposited  and  processed.  It  is  easiest  to  think  about 
them  as  mailboxes. 

Among  the  addresses  in  an  addressing  scheme  there  may  be  some  which 
never  originate  or  keep  messages.  They  always  forward  messages  to  other 
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addresses.  We  will  call  such  addresses  routing  addresses.  The  rest  of  the 
addresses  where  messages  can  originate  or  be  deposited  will  be  called  mail 
ajddresses. 

A  state  of  an  addressing  scheme  is  a  partition  allowing  repetition  of  a  set  of 
available  messages  from  into  the  set  of  addresses.  We  will  interpret  the  set 
of  messages  associated  with  on  address  as  the  messages  received  by  but  not  yet 
processed  by  the  address  It  is  obvious  that  not  all  partitions  of  messages  con¬ 
stitute  reachable  states  of  an  addressing  scheme. 

The  input  to  the  addressing  scheme  is  a  sequence  of  pairs  (m,a)  indicating 
the  generation  of  a  message  m  in  the  address  a.  Each  pair  involves  a  different 
message.  That  is,  a  message  can  originate  only  once  in  the  model.  A  new  ver¬ 
sion  of  the  message  will  have  different  id  even  if  it  has  the  same  contents. 

The  definition  of  an  addressing  scheme  includes  a  description  of  allowable 
messages  and  a  definition  of  the  directed  graph  of  addresses.  However,  the  criti¬ 
cal  part  of  an  addressing  scheme  is  the  set  of  allowable  states  and  the  mapping 
between  states,  i.e.,  how  messages  circulate  in  the  mail  network. 

One  way  of  describing  the  mapping  of  an  addressing  scheme  is  to  define  a 
next  state  mapping  between  states  which  is  local,  i.e.,  it  involves  the  handling 
of  a  single  message  in  a  single  station.  We  start  with  ein  initial  empty  state  indi¬ 
cating  that  no  messages  circulate.  The  next  state  mapping  has  four  cases. 

1)  It  inserts  a  message  m  in  an  address  a  (generation  of  a  new  message). 

2)  It  moves  a  messeige  m  present  in  an  address  a  to  an  other  address  con¬ 
nected  with  it  (message  forwarding). 

3)  It  consumes  a  message  m  present  in  an  address  a  (message  reaching  one 
of  its  targets). 
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4)  It  keeps  a  message  m  in  an  address  a  and  it  forwards  a  copy  of  it  to  an 
address  connected  with  it  (message  reaching  a  target  and  being  for¬ 
warded). 

Suppose  that  a  message  scheme  is  specified  by  giving  a  definition  of  the 
next  state  mapping.  The  next  state  mapping  can  be  extended  into  a  state  map¬ 
ping  defined  from  state  to  if  there  exists  a  series  of  next  state  mappings 
which  can  get  the  system  from  to  . 

Suppose  now  that  we  want  to  follow  the  progress  of  a  particuleir  messeige  m. 
Let  Si  be  the  state  obtained  immediately  after  the  insertion  of  m  in  address  a. 
The  set  of  addresses,  s.t.,  m  is  in  them  for  some  state  S  reachable  from  52,  will 
be  Ccdled  the  reachability  set  of  addresses  for  the  message  m.  The  subset  of 
R  where  m  is  delivered  will  be  called  the  scope  0^  of  the  message  m, 

A  nice  way  of  representing  the  progress  of  a  message  m  is  by  constructing 
a  tree  of  addresses  from  which  m  passes.  Adresses  may  appear  many  times  on 
the  tree  and  can  be  flagged  to  denote  whether  m  is  delivered  there. 

Consider  two  addressing  schemes  such  that  there  is  a  one  to  one 
correspondence  between  their  mail  addresses  and  they  deal  with  the  same  gen¬ 
eric  set  of  messages.  The  addressing  schemes  can  potentiably  have  different 
sets  of  routing  addresses,  different  connectivity  networks  and  different  mapping 
definitions.  We  can  define  in  this  case  a  notion  of  equivalence  if  the  two 
addressing  schemes  eventually  deliver  the  messages  to  the  same  addresses. 
They  may  treat  each  message  differently  but  the  final  destinations  are  the 
same.  Two  compatible  addressing  schemes  are  equivalent  if  for  each  message 
rri  which  can  potentially  originate  in  corresponding  addresses  the  scopes  of  the 
message  are  the  same.  Note  that  the  practical  problem  is  not  to  check  whether 
two  arbitrary  addressing  schemes  are  equivalent.  We  are  rather  interested  in 
{performing  equivalence  preserving  transformations  and  restructuring  of  an 


-7- 


addressin^  scheme  into  another  "better’',  but  equivalent,  addressing  scheme. 

3.  Categories  of  addressing  schemes 

We  identify  certain  categories  of  addressing  schemes  which  represent  par¬ 
ticular  techniques  in  addressing  messages. 

First,  we  distinguish  address  logic  schemes  as  opposed  to  message  logic 
schemes,  In  the  address  logic  schemes  messages  are  completely  passive.  The 
routing  procedure  of  the  messages  are  associated  with  the  addresses.  The  logic 
present  in  these  procedures  establishes  whether  the  address  should  keep  a 
received  message,  to  >vhere  it  should  forward  it  and  whether  it  should  change 
any  values  on  the  message.  In  message  logic  addressing  schemes  all  logic 
resides  in  messages.  When  a  message  arrives  at  an  address  it  obtains  the 
address  Identification  and  it  has  access  to  the  information  present  in  the 
address.  Tne  message,  as  an  object,  has  its  own  procedures  to  decide  whether  it 
should  leave  a  copy  of  itself,  to  what  addresses  it  should  go  next  and  whether  it 
should  retain  some  information  available  to  it.  In  address  logic  schemes  mes¬ 
sages  are  data  structui  es  which  flow  between  addresses,  trigger  the  procedures 
residing  in  addresses  and  are  processed  by  them.  In  message  logic  schemes 
messages  are  objects  with  their  own  procedures  [Vittal  81].  Addresses  are  pas¬ 
sive  data  structures.  Messages  visit  addresses,  they  make  appropriate  changes 
and  then  move  on.  We  can  have,  of  course,  mixed  addressing  schemes  where 
both  messages  and  addresses  are  independent  objects.  Their  interaction 
represents  a  cooperation  for  addressing  the  messages,  according  to  a  preesta- 
bUshed  contract. 

We  will  consider  more  carefully  address  logic  schemes.  In  this  area  we  can 
identify  some  interesting  cases.  We  cein  distinguish  between  routing  logic, 
sender  logic:  and  receiver  logic  addressing  schemes.  In  the  routing  logic 
schemes  all  decisions  about  where  the  messeiges  should  go  are  made  by  the 
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routin^  stations.  The  routing  stations  receive  and  forwcird  all  messages  and 
they  have  complete  control  for  the  delivery  of  the  messages  to  the  receiver 
addresses.  The  senders  provide  data  about  where  the  massages  should  go,  How¬ 
ever,  their  suggested  receiver  specifications  eire  not  necessarily  binding  to  the 
routing  stations.  In  sender  addressing  schemes  the  destination  of  the  mes¬ 
sages  is  completely  decided  by  the  sender  addresses.  All  addressing  logic  rests 
in  procedures  available  to  the  sender.  He  specifies  the  exact  receiver  addresses 
where  the  message  is  supposed  to  go.  The  rest  of  the  routing  addresses  have  no 
decision  as  to  final  destination.  In  receiver  logic  schemes  addressing  logic 
rests  with  the  receiver.  Each  message  is  broadcasted  to  all  addresses  and  an 
address  has  potential  access  to  all  messages.  The  receiver  addresses  identify 
eind  accept  any  message  they  wemt.  Receiver  logic  addressing  schemes  behave 
in  essence  like  data  base  systems  where  all  messages  are  posted  and  are  avail¬ 
able  to  all  addresses.  We  can,  of  course,  have  mixed  schemes  where  the  logic 
for  addressing  the  messages  is  distributed  in  the  sender,  receiver  and  routing 
addresses.  The  distinction  between  sender,  receiver  and  routing  logic  schemes 
applies  also  to  message  logic  schemes  in  an  indirect  way.  In  message  logic 
schemes  the  messages  have  to  inherit  their  routing  logic  from  somewhere,  i.e., 
from  sender,  routing  or  receiver  addresses. 

Notice  that  the  distinctions  between  message  and  address  logic  schemes 
and  the  further  distinction  between  routing,  sender  and  receiver  addressing 
schemes  are  made  at  the  logical  level.  The  addressing  procedures  are  logically 
associated  with  messages  routing  addresses,  sender  addresses  and  receiver 
addresses.  The  schemes  can  be  implemented  as  centralized  or  distributed.  For 
instance,  we  can  have  a  routing  logic  addressing  scheme  which  is  centralized  or 
it  is  distributed  among  many  routing  stations. 

Most  electronic  mail  systems  available  today  use  sender  logic  addressing 
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schemes.  They  are  implemented  in  a  centralized-  fashion  within  one  large 
mainframe  computer,  or  they  are  implemented  in  a  distributed  fashion  using  a 
network  of  computers.  Two  reasons  seem  to  account  for  this  situation.  First,  in 
many  existing  message  systems  there  are  many  more  messages  than 
addresses.  Hence,  it  is  easier  to  associate  routing  procedures  with  addresses 
rather  than  messages.  Second,  messages  are  considered  passive  objects  while 
mail  stations  are  supposed  to  incorporate  intelligence.  Hence,  procedures  are 
more  easily  associated  with  mail  stations.  These  two  factors  for  the  utilization 
of  address  logic  schemes  may  become  less  important  in  the  future. 

4.  Comparisons  and  Reductions 

In  this  section  we  will  try  to  compare  different  addressing  schemes.  This 
comparison  will  point  out  some  of  their  properties.  For  the  purposes  of  com¬ 
parison  we  will  keep  in  mind  the  notion  of  equivalence  as  outlined  in  section  2. 
A  category  A  of  addressing  schemes  covers  a  category  B  if  for  each  addressing 
scheme  of  B  there  is  an  equivalent  addressing  scheme  in  A.  Two  categories 
have  the  same  power  if  they  cover  each  other.  In  all  our  subsequent  discus¬ 
sions  we  will  assume  a  closed  model,  that  is,  all  decisions  regarding  addressing 
are  part  of  the  model.  In  an  open  model  decisions  e.g.,  by  humans,  can 
influence  addressing  but  are  not  specified  as  an  integral  part  of  the  addressing 
scheme.  We  will  make  a  special  note  if  we  will  depart  from  the  closed  model 
assumption. 

The  first  broad  comparison  is  between  message  logic  and  address  logic 
schemes.  Consider  a  given  address  logic  scheme.  All  routing  procedures  are  by 
definition  part  of  the  addresses.  Since  there  are  only  a  finite  number  of 
addresses  all  these  procedures  can  be  represented  by  one,  albeit  complicated, 
procedure  P.  Suppose  now  we  augment  each  message  with  P  and  a  process 
which  tests  the  identify  of  an  address  and  gives  control  to  the  appropriate 
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procedure  within  P .  In  this  way  we  can  derive  a  message  logic  scheme  which  is 
equivalent  in  an  obvious  way  to  the  original  address  logic  scheme.  Notice,  how¬ 
ever,  certain  issues.  Hrst,  each  message  will  be  burdened  with  all  the  address¬ 
ing  logic,  including  the  procedures  of  addresses  it  may  never  visit.  Second,  if 
messages  are  many  more  than  addresses,  it  is  a  waste  of  space  to  repeat  the 
addressing  logic  within  all  messages.  Third,  if  a  new  address  is  added  to  the 
model  all  sender  addresses  should  know  about  this  addition  so  they  can  incor¬ 
porate  the  necessary  changes  into  the  message  logic.  On  the  other  hand, 
addresses  are  empty  of  logic.  That  means  that  any  naked  machine  cein  serve  as 
a  routing  station.  In  this  environment  personal  computers  used  for  other  pur¬ 
poses  can  route  messages  without  any  local  expertise  in  addressing  messages. 

Consider  now  a  given  message  logic  scheme.  A  finite  description  of  the 
scheme  implies  that  all  messages  fall  within  a  finite  number  of  categories  in 
terms  of  addressing  logic.  Consider  all  the  addressing  procedures  available  in 
all  categories  of  messages.  We  denote  by  P  the  collective  routing  logic 
represented  by  all  these  procedures.  We  construct  an  address  logic  scheme 
which  has  in  each  address  P  eind  a  process  which  identifies  the  message 
category  and  gives  control  to  the  appropriate  procedure  within  P.  This  address 
logic  scheme  is  again  equivalent  in  an  obvious  way  to  the  original  message  logic 
scheme.  Notice  again  certain  issues.  First,  addresses  may  be  burdened  with 
routing  logic  of  messages  they  may  never  see.  Second,  if  there  are  many  more 
addresses  than  messages  (and  this  can  happen  if  any  person,  role,  location  is  an 
address)  the  message  routing  logic  will  be  copied  all  over  the  place.  Third,  if  a 
new  category  of  messages  is  added  the  appropriate  routing  logic  should  be  sent 
to  all  addresses. 

We  argued  that  the  power  of  message  logic  scheme  equals  the  power  of 
address  logic  schemes.  In  addition,  address  logic  schemes  have  advantages  if 
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there  are  many  more  messages  than  addresses,  categories  of  messages  are 
rather  static  and  routing  stations  have  all  the  needed  procedures  for  address¬ 
ing.  This  is  definately  the  situation  in  many  existing  mail  systems.  Message 
logic  schemes  have  advantages  if  there  are  many  addresses,  message 
categories  are  very  dynamic  and  stations  are  available  everywhere  which  serve 
other  purposes  and  not  particularly  message  addressing.  We  feel  that  this  will 
probably  be  the  case  in  the  future.  We  also  feel  that  the  best  addressing 
schemes  will  be  mixed  incorporating  address  logic  for  the  known  and  static 
categories  of  messages,  but  being  able  to  handle  ad  hoc  messages  provided  they 
include  their  own  routing  logic. 

The  second  comparison  is  between  routing,  sender  and  receiver  addressing 
schemes.  To  compare  these  different  schemes  we  will  use  the  following  reduc¬ 
tion  process. 

Consider  an  address  y  and  the  set  of  addresses  jx  j  sending  messages  to  it 
and  the  set  of  addresses  \z]  receiving  messages  from  it.  We  denote  by  Pg,Py,Pz 
the  appropriate  message  routing  procedures.  Suppose  that  we  substitute  in 
each  Pj^  the  command  sending  a  message  to  y  by  the  invocation  of  Py  with  the 
message.  This  will  imply  that  each  time  a  message  was  supposed  to  be  for¬ 
warded  to  y  it  will  invoke  the  routing  logic  of  y  and  it  will  go  directly  to  where 
y  was  sending  it.  Notice  that  there  is  the  possibility  that  an  address  x  mil 
invoke  itself  if  y  was  sending  the  message  back  to  it.  Provided  that  x  can  keep 
a  queue  of  messages,  or  it  can  multiprogram  the  different  invocations  there  is 
no  problem.  By  duplicating  the  routing  logic  of  y  in  each  address  x  which  can 
potentially  send  messages  to  y  messages  can  bypass  y.  If  1/  is  a  routing  station 
then  it  can  be  eliminated  while  retaining  an  equivalent  addressing  scheme. 
This  process  will  be  called  a  backward  reduction.  In  a  dual  manner  we  can 
export  the  routing  logic  of  y  to  all  addresses  receiving  messages  from  it.  We 
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substitute  in  the  routing  logic  of  each  x  a  broadcast  to  all  addresses  z  each 
time  a  message  was  supposed  to  go  to  y.  In  each  z  we  incorporate  the  logic  of 
y.  It  retains  the  message  if  it  was  supposed  to  be  sent  by  y  to  the  address  z 
and  it  drops  it  otherwise.  In  this  manner  each  message  going  from  an  x  to  y 
will  go  to  all  z  connected  to  y.  It  will  then  be  passed  to  the  routing  logic  of  the 
address  z  only  if  it  was  supposed  to  be  sent  from  y .  By  this  process  the  address 
y  can  be  bypassed.  If  y  is  a  routing  address  it  can  be  eliminated  while  retain¬ 
ing  an  equivalent  addressing  scheme.  The  process  will  be  called  a  forward 
reduction.  Notice  that  in  both  reductions  we  use  heavily  the  assumption  of  a 
closed  model.  If  the  routing  decision  in  y  depended  on  a  local  environment 
which  is  not  closed  we  could  not  carry  this  environment  back  and  forth. 

Suppose  now  that  we  have  a  routing  addressing  scheme.  By  using  either 
backward  or  forward  reduction  we  can  move  the  routing  logic  towards  the 
senders  or  receivers.  "We  can  eventually  incorporate  all  routing  logic  within  the 
senders  or  the  receivers.  In  this  way  we  can  turn  a  sender  logic  into  a  receiver 
logic  scheme  and  vice  versa.  It  follows  that  sender  logic,  receiver  logic,  and 
routing  logic  schemes  have  equal  power.  Notice,  however,  that  these  transfor¬ 
mations  can  be  quite  messy.  In  both  forward  eind  backward  reduction  we 
heavily  duplicate  local  routing  procedures.  A  nicely  structured  addressing 
scheme  can  become  quite  unwieldy  by  using  the  reduction  process.  This  para¬ 
graph  points  out,  however,  a  rather  nice  association.  Sender  logic  schemes, 
which  is  the  way  most  electronic  mail  systems  are  today,  have  the  same  power 
to  communicate  as  receiver  logic  schemes,  which  is  the  way  that  data  base 
management  systems  effect  communication.  In  essence,  we  find  the  same 
analogy  as  in  [Tsichritzis  1981],  that  electronic  mall  and  data  base  systems  are 
two  different  but  equivalent  ways  to  communicate. 

The  routing  procedures  in  a  closed  model  can  be  implemented  either  cen- 


-  13- 


trally  or  in  distributed  fashion.  We  can  change  centralized  to  distributed  sys¬ 
tems  and  vice  versa  depending  on  whether  we  run  the  routing  processes  in  the 
same  or  different  stations.  The  basic  issues  of  this  decision  are  related  to  per¬ 
formance  of  both  computers  and  networks. 

5.  Properties 

Suppose  we  provide  a  sequence  of  input  messages  to  an  addressing  scheme. 
It  is  desirable  that  all  messages  reach  their  destinations.  No  message  should 
get  stuck,  or  circulate  forever.  It  may  also  be  desirable  that  relative  speeds  in 
processing  the  messages  in  different  addresses  do  not  affect  the  final  destina¬ 
tion. 

An  addressing  scheme  will  be  called  complete  if  it  eventually  delivers  all 
possible  generated  messages,  i.e.,  any  sequence  of  messages  originating  in  the 
scheme  get  eventually  delivered  and  the  scheme  reaches  the  empty  state.  An 
addressing  scheme  will  be  called  time  independent  if  for  each  message  its  final 
destination(s)  does  not  depend  on  the  sequence  of  appl3dng  the  next  state  map¬ 
ping  in  the  network.  That  is,  the  time  needed  to  process  the  message  in  each 
address  does  not  affect  where  the  message  gets  delivered. 

An  addressing  scheme  will  be  called  memoryless  if  an  address  does  not 
retain  information  from  the  messages  which  have  reached  it  in  the  past  includ¬ 
ing  the  messages  delivered.  (They  are  outside  the  model  after  their  accep¬ 
tance).  An  addressing  scheme  will  be  called  coordination  free  if  its  mapping 
handles  each  message  separately  without  being  affected  by  the  presence  of 
other  messages.  Note  that  both  memory  and  coordination  may  be  desirable 
properties  for  addressing  schemes.  Their  presence,  however,  greatly  compli¬ 
cates  the  operation  and  the  analysis  of  an  addressing  scheme. 

It  is  interesting  to  discuss  the  extent  to  which  memory  and  coordination 
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increase  the  power  of  addressing  schemes.  In  this  section  we  will  talk  in  terms 
of  memory  In  addresses.  Memory  cein  also  be  used  within  messages  in  a  dual 
way.  Before  we  compare  memory  emd  memoryless  schemes  we  need  to  be  more 
careful  in  defining  what  we  mean  by  the  presence  of  memory.  By  memory  we 
may  imply  two  different  situations.  The  first  issue  is  whether  we  allow  the 
addresses  to  retain  information  regarding  messages  handled,  i.e.,  to  have 
memory.  The  second  issue  is  the  means  for  storing  the  information,  i.e.,  to  use 
memory.  It  is  obvious  that  addressing  schemes  which  are  allowed  to  have 
memory  can  do  certedn  operations  impossible  to  schemes  which  are  not 
allowed.  For  instance,  suppose  we  want  to  drop  a  message  if  the  same  sender 
has  already  sent  10  messages  before.  How  can  we  implement  this  if  we  are  not 
allowed  to  retain  the  name  of  the  sender  and  a  counter  to  count  the  messages 
sent? 

Suppose  that  we  allow  addresses  to  keep  information  regarding  messages. 
We  need  to  define  how  much  memory  addresses  have  and  how  they  use  it. 
Addresses  can  have  a  finite  number  of  states  as  memory,  a  finite  number  of 
variables,  a  finite  number  of  passed  messages,  or  an  unbounded  amount  of 
memory.  We  also  need  a  technique  for  comparing  schemes.  Sofar  we  were  deal¬ 
ing  with  categories  which  had  the  same  power.  We  used,  therefore,  the  method 
of  mapping  an  addressing  scheme  in  one  category  into  an  equivalent  scheme  of 
the  other.  To  show  that  one  category  strictly  covers  the  other  we  need  to  find 
schemes  in  the  first  not  available  in  the  second.  As  an  alternative  we  need  to 
express  the  power  of  each  category  in  some  closed  form  and  then  compare 
them. 

Consider  any  addressing  scheme.  Messages  handled  by  the  scheme  can  be 
encoded  into  numbers  in  a  unique  fashion  by  using  any  standard  encoding  tech¬ 
nique.  The  procedures  available  in  each  address  are  modified  to  unpack  the 
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numbers  representing  the  messages  and  then  to  process  them.  Before  sending 
the  message  it  is  packed  again  into  a  number.  The  addresses  where  the  mes¬ 
sages  are  sent  are  also  packed  into  the  number.  In  this  way  we  can  express  the 
handling  of  a  message  in  an  address  x  by  a  function  F^im).  This  function  is 
partially  recursive  if  we  allow  an  arbitrary  program  to  process  the  message  in 
an  address.  It  is  totally  recursive  if  we  insist  that  each  address  has  to  deal  with 
the  message.  That  is,  it  can  not  take  an  infinite  amount  of  time  to  decide  how 
to  handle  the  message.  The  result  of  all  the  invocations  of  in  all  the 
addresses  can  also  be  expressed  by  a  function  F{m)  which  represents  the  total 
processing  of  a  message  m.  Note  that  this  function  is  partially  recursive  even 
in  the  case  that  each  F^  is  total.  This  situation  represents  the  fact  that  we  can 
combine  the  different  programs  and  get  a  global  program  which  may  never  halt 
even  if  each  piece  always  halts.  We  have  a  control  structure  in  the  way  that 
messages  flow  between  addresses. 

We  can  now  make  some  observations  regarding  memory.  First,  if  we  bound 
all  but  one  variable  in  one  address  we  have,  in  essence,  infinite  memory.  We 
can  collapse  all  addresses  to  the  address  having  memory  by  reduction  and  use 
the  one  available  variable  for  storing  all  the  information  regarding  passed  mes¬ 
sages.  All  the  addressing  schemes  which  have  somewhere  unbounded  memory 
(even  in  one  place)  fall  within  one  category.  Their  handling  of  messages  is 
represented  by  partially  recursive  functions.  Consider  now  schemes  which 
have  bounded  memory  of  all  aspects,  i.e.,  number  of  variables,  size  of  variables. 
Each  one  of  these  schemes  has  a  finite  number  of  states.  There  is,  therefore,  a 
second  category  of  addressing  schemes  whose  handling  of  messages  can  be 
represented  by  the  class  of  finite  automata.  In  addition,  there  are  more 
categories  if  we  bound  the  complexity  of  routing  programs  in  each  address  in  a 
meaningful  way  and  we  also  bound  the  number  of  routing  addresses.  The 
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second  bound  is  necessary  because  addresses  can  be  easily  split  in  series  to 
reduce  the  complexity  of  each  one. 

Consider  now  coordination.  Schemes  with  coordination  can  get 
deadlocked,  while  without  it  there  is  no  possibility  of  this  situation  occurring. 
There  is,  however,  the  possibility  that  messages  circulate  forever  even  without 
coordination.  If  a  scheme  with  coordination  can  be  simulated  by  an  equivalent 
scheme  without  it  this  situation  would  necessarily  happen.  That  is,  in  the  non 
coordinating  scheme  a  message  would  circulate  forever  if  the  same  message 
gets  stuck  in  the  coordinating  scheme.  We  can,  in  fact,  simulate  the  coordina¬ 
tion  in  the  following  way.  Consider  an  address  x  which  does  coordination  as 
expressed  by  a  predicate  7’(mi,m2),  Any  two  messeiges  m2  and  mg  will  be  pro¬ 
cessed  only  if  the  predicate  is  true,  else  they  will  have  to  wait.  We  modify  the 
addressing  scheme  by  introducing  a  new  coordinating  address  y  associated  with 
T.  We  modify  the  message  handling  logic  of  x  by  eliminating  the  coordination 
and  shipping  instead  the  messages  subject  to  coordination  to  y.  The  address  y 
has  space  to  store  locally  one  message  (more  if  the  coordination  involves  more 
messages).  When  a  message  arrives,  the  address  y  checks  to  see  whether  T  is 
true  between  the  newly  arrived  message  and  the  copy  it  has  in  the  local  store. 
If  7  is  true  the  newly  arrived  message  and  the  one  in  the  local  store  is  sent  to  x 
for  processing  (coordination  is  successful).  If  T  is  false  it  sends  the  messeige  to 
a  bouncing  address  2 .  The  address  2  just  sends  back  to  y  all  received  mes¬ 
sages.  If  the  message  received  by  y  is  exactly  the  same  as  the  one  in  the  local 
store,  it  erases  the  local  store  and  sends  back  the  message  to  2  (try  another 
message  for  coordination).  If  a  message  arrives  and  finds  the  local  store  empty 
it  IS  stored  there  before  going  to  2  (try  this  one  for  matching).  If  it  comes  from 
X  it  just  goes  to  2  (to  avoid  effective  deadlock).  This  scheme  will  ensure  that 
all  messages  which  were  successfully  coordinated  in  x  they  will  be  processed  by 
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it.  All  messages  waiting  for  coordination  will  bounce  back  and  forth  between  y 
and  z  until  they  get  coordinated.  Any  message  which  was  getting  stuck  in  the 
original  scheme  would  circulate  forever  in  the  new  one.  By  applying  this  pro¬ 
cess  to  all  coordinating  addresses  of  a  scheme  we  can  get  an  equivalent  scheme 
which  actually  has  the  same  effect  by  doing  a  very  elementary  type  of  coordina¬ 
tion,  i.e.,  matching  a  message  with  one  it  holds.  This  situation  should  come  as 
no  surprise.  In  effect,  we  simulate  the  coordination  logic  as  it  would  happen  in 
an  address  by  using  the  control  structure  of  the  address  network. 

6.  IWte  state  addressizig  schemes 

One  way  of  defining  the  mapping  of  addressing  schemes  is  by  expressing 
the  local  routing  in  terms  of  patterns  appearing  in  the  messages.  Consider  the 
messages  as  strings  over  a  finite  alphabet  1.  Messages  can  be  thought  of  as  text 
messages,  although  other  types  of  messages  can  be  expressed  as  strings,  e.g., 
voice  messages  in  terms  of  phonemes.  Consider  an  address  -x  and  all  the 
addresses  to  which  x  can  send  messages.  Messeiges  present  in  x  will  be  for- 
weaded  to  an  address  y  iff  a  pattern  is  present  in  the  messages.  Each  pat¬ 
tern  can  be  expressed  as  a  regular  expression  over  the  alphabet  1  [Aho  et  al 
1974].  The  messages  incorporating  are  of  the  form  I* p^y  he.,  p^y  as  a 
regular  expression  defines  a  string  present  somewhere  in  the  message.  The  set 
of  qualified  messages  according  to  a  pattern  p^y  will  be  denoted  as  R^y.  Pat¬ 
terns  can  be  used  to  express  conditions  like  a  name  appears  in  the  message,  an 
address  specification  appeeirs  in  the  message,  etc.  For  example,  post  office  mail 
routing  can  be  expressed  by  checking  for  patterns  representing  country  name, 
city  name,  street  name,  etc. 

We  will  use  the  following  notation.  Given  two  patterns  p^  and  p„.  the  pat¬ 
tern  p,^  vp^jj  will  be  represented  as  p|^  and  it  will  specify  the  disjunction  of 
the  two  patterns.  The  set  of  messages  qualified  by  pj^*  will  be  denoted  as 
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and  it  will  correspond  to  [  J  Hxz  This  notation  will  be  extended  in  the  obvi¬ 
ous  manner 

=  Pxy^-  '^^Prw  and  Ry  U  ’  ’  ’  U  ^ 

Given  two  patterns  andjo^,,  the  pattern  '^Pyz  will  be  represented  osp^yz 

amd  it  will  specify  the  conjunction  of  the  presence  of  the  two  patterns.  The  set 

of  messages  qualified  by  p^^z  will  be  denoted  as  and  it  will  correspond  to 

Pi  • 

Notice  that  the  conjunction  will  be  interpreted  in  terms  of  having  the  pat¬ 
tern  pjcy  cmd  the  pattern  Pyg  appearing  in  the  message,  that  is  the  pattern 
U*Pxy^  r]^*Pyzf*)  and  not  necessarily  the  pattern  (p^^  DPyz)  as  a  regular 
expression.  For  example,  if  p^  is  "Greece"  andpy^  is  "Athens"  we  will  be  look¬ 
ing  for  messages  which  incorporate  "Greece"  and  "Athens"  and  not  the  string 
("Greece"  n  "Athens")  which  will  qualify  no  messages. 

Given  a  pattern  p,  defining  R  set  of  messages  we  will  denote  as  ~p  the 
absence  of  p  in  the  message.  The  pattern  ~p  qualifies  the  complement  of 
R,  in  terms  of  the  generic  set  of  messages. 

k  finite  state  message  addressing  scheme  is  defined  by; 

a)  A  finite  set  of  addresses.  We  will  use  small  letters  a.b,...  to  denote 
addresses. 

b)  A  directed  graph  defining  the  connectivity  between  addresses. 

Each  edge  {x,y)  of  the  graph  will  be  labelled  by  a  pattern  p^g.  The  graph 
will  be  represented  by  a  matrix  P{x,y)  having  an  entry  p^^,  for  each  edge.  For  a 
pair  of  addresses  [z  .'w)  which  are  not  connected  p^  will  be  set  to  /  (false)  sig¬ 
nifying  the  impossible  pattern.  If  all  messages  appearing  in  x  go  to  y  the  pat¬ 
tern  pzy  will  be  set  to  t  (true)  signifying  the  always  present  pattern.  The 
matrix  P{x,y)  will  be  augmented  by  a  row  P{q  ,x)  specifying  patterns  po*  quali- 
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tying  all  the  messages  originating  at  address  x  and  a  column  Pix,^)  qualifying 
all  the  messages  retained  to  an  address  x. 

We  make  the  assumption  that  an  address  does  not  change  the  messages,  or 
at  least  it  does  not  alter  them  in  any  way  which  affects  the  patterns  defining 
the  routing.  The  scheme  allows  the  possibility  that  a  message  m  in  x  can  be 
forwarded  to  more  than  one  next  address.  We  do  not  insist  that  R^y  H 

In  our  definition,  up  to  now,  an  address  did  not  have  any  memory.  The 
routing  was  not  affected  by  the  passing  messages.  In  such  a  case,  we  will  see 
that  the  specification  of  patterns  in  P{x,y)  separates  the  messages  into  a  finite 
set  of  equivalence  classes,  each  class  corresponding  to  a  particular  message 
path.  We  can  expand  the  definition  by  allowing  a  finite  amount  of  memory  in  an 
address.  We  assume  without  loss  of  generality  that  addresses  with  memory 
route  messages  to  one  next  address  according  to  their  state.  Further  distribu¬ 
tion  can  be  affected  from  there.  We  also  assume  without  loss  of  generality  that 
the  state  transitions  within  an  address  are  deterministic.  Non  deterministic 
behaviour  can  be  simulated  by  deterministic  behaviour  since  we  are  dealing 
with  a  finite  number  of  states  [Aho  et  al  1974].  We  will  denote  addresses  with 
memory  by  Greek  small  letters  ■  •  ■  etc. 

Consider  an  address  a  with  memory.  The  address  can  be  in  any  one  of  n 
states  •  •  •  .s„J,  with  Sj  the  initial  state.  When  a  message  m  arrives  in  a  it 
finds  the  address  in  some  state  The  message  first  invokes  a  state  change, 
-*  Sy,  depending  on  whether  a  pattern  is  present  in  the  message.  After  the 
state  changes  to  Sj  all  messages  present  in  a  will  go  to  an  address  yj  provided 
they  satisfy  a  pattern  relating  state  Sj  to  the  address  A  message  m  is 
trapped  until  address  a  reaches  a  particular  state  from  where  it  can  proceed. 
Notice  that  the  arrival  of  a  message  and  not  its  presence  forces  a  state  change. 
At  a  given  point  there  may  be  many  messages  waiting  in  a  and  they  will  not 
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change  the  state.  We  would  expect  that  for  the  addresses  [yj]  to  which  tx  can 
send  messages  Payi'^'^ Payz^ '  •  •  '^''Payn  is  always  true,  or  "  represents 
all  messages.  If  not,  a  message  m  may  reach  a  and  stay  there  forever.  On  the 
other  hand,  maybe  the  messages  in  never  reach  a  in  which  case  the 

addressing  scheme  works  fine. 

The  state  transitions  in  a  are  represented  by  a  matrix  Qai'^J)  with  entries 
qij  for  each  pair  s^.Sj.  If  there  is  no  message  taking  address  a  from  to  sj  then 
qij  will  be  set  to  /,  the  impossible  pattern.  For  a  given  station  a  q^  is 

also  impossible  because  of  our  assumption  of  deterministic  behaviour.  The 
entry  qa  is  set  to  ~(gii •  v  \/ v  •  ■  •  v  g^).  or  in  our  notation 
q,^i2...(i-i)(i+i)  •  •  •  n  definition  of  a  finite  addressing  scheme  is  augmented  in 
the  presence  of  memory  by  introducing  the  state  transition  matrix  for 

each  memory  address  a.  The  matrix  P{x  ,y)  of  the  scheme  will  encode  the  pat¬ 
terns  for  each  address  y  connected  to  a  state  of  a. 

Consider  some  examples  to  illustrate  finite  state  addressing  schemes. 

Figure  1  demonstrates  a  simple  medl  sorting  scheme  into  mailboxes 
according  to  the  "name”  appearing  in  the  message.  Figure  2  has  a  scheme  with 
memory  which  takes  a  streaim  of  messages  and  alternatively  sends  them  to  two 
different  addresses.  Figure  3  demonstrates  how  a  scheme  with  memory  can 
batch  messages  until  a  particular  message  arrives.  Finally,  the  example  in  Fig¬ 
ure  4  demonstrates  how  messages  can  interfere  with  each  other  and  their  desti¬ 
nation  may  be  time  dependent.  If  a  message  rrij  arrives  in  a  without  any  mes¬ 
sage  being  processed  by  it  will  go  to  /3  then  return  to  a  and  then  go  to  y.  In 
the  same  way  a  message  mg  appearing  alone  in  §  will  go  to  a  and  come  back  and 
exit  to  z.  Suppose  now  that  m^  arrives  in  a  and  mg  arrives  in  almost  simul¬ 
taneously.  Message  m^  will  cheinge  a  to  sg  and  go  to  In  the  meantime  mg 
arrives  and  changes  p  to  sg,  and  goes  to  a.  The  message  m^  finds  /?  in  Sg  it 
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changes  to  and  exits  to  z.  The  message  mg  finds  a  in  sg  changes  to  Sj,  and 
exits  to  y.  In  this  way  mi, m2  will  switch  and  go  to  z  ,y  respectively,  if  they 
arrive  almost  simultaneously.  If  they  arrive  with  some  time  apart  they  will  go 
to  y.z  respectively.  This  behaviour  is  time  dependent  and  in  some  cases  it 
should  be  avoided. 

7.  VWialyais  finite  state  addressing  schemes 

Given  an  addressing  scheme  it  would  be  nice  if  we  can  analyze  its  routing. 
The  analysis  can  not  apply  to  all  different  addressing  schemes,  since  they  can 
simulate  programs  which  incorporate  even  parallelism.  However,  in  special 
cases  we  maybe  able  to  investigate  their  properties. 

Consider  a  finite  state  addressing  scheme  without  memory  consisting  of 
addresses  x,y,  •  ■  ■  ,w  and  their  connectivity  matrix  P{x ,y).  Given  a  particular 
path  x,y,  -  ,z  the  set  of  messages  which  once  they  appear  in  x  follow  this 
path  is  given  by  ^  . . .  ^ .  This  can  easily  be  shown  by  induction  in  terms  of  the 
length  of  the  path.  The  set  of  messages  arriving  in  x,  following  the  path 
ay  ••  X,  is  qualified  by  Poy  x-  The  set  of  all  messages  arriving  in  x  is 
expressed  as  p^^  .  '^Pow  •  x  ’  •  for  all  the  paths  which  end  in  x  and  mes¬ 
sages  originating  in  some  address  y.'w,  •  •  •  .  etc.  We  can  obtain  all  these  pat¬ 
terns  by  doing  a  depth  first  search  of  the  address  connecting  graph  starting 
with  the  hypothetical  source  address  o  [Aho  et  al  1974].  We  only  need  to  look  at 
paths  of  finite  length.  Once  a  path  becomes  longer  than  the  number  of 
addresses  one  of  the  addresses  would  repeat  and  we  have  its  behaviour 
e)q)ressed  higher  in  the  tree.  Care  should  also  be  taken  to  prune  the  tree  of  the 
paths  which  have  patterns  qualifying  no  messages. 

FVom  the  tree  we  can  obtain  all  the  information  we  need  regarding  the 
routing  of  the  messages.  For  each  address  we  can  obtain  the  qualification  of  all 
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messages  passing  from  that  address  and  all  messages  retained  in  the  address. 
For  each  cycle  we  can  check  whether  messages  get  in  that  cycle.  A  nice  way  of 
representing  the  messages  is  to  use  a  bit  vector  with  one  bit  position  for  each 
pattern  present  in  the  addressing  scheme.  We  start  out  with  a  vector  full  of 
"d"  (don’t  care)  at  the  source  address.  As  we  go  down  each  path  we  ceirry  the 
vector  and  we  turn  bits  on  to  "1”  every  time  we  need  a  pattern  to  be  present  in 
the  message,  or  to  "0"  when  we  do  not  want  the  pattern  to  be  present  (nega¬ 
tion).  All  messages  which  correspond  to  a  particular  bit  vector  are  handled  by 
the  addressing  scheme  in  the  same  way.  The  bit  vectors  and  associated  paths 
define  a  set  of  equivalence  classes.  For  each  class  the  messages  start  at  a  par¬ 
ticular  address  and  either  they  end  at  a  specific  address  or  they  follow  a  partic¬ 
ular  cycle. 

From  the  previous  discussion  it  folows  that  a  way  to  implement  an  address¬ 
ing  scheme  without  memory  is  to  check  each  message  for  all  the  patterns 
in  one  pass  and  construct  the  bit  vector.  A  finite  automaton  can  then  process 
the  vector  and  obtain  the  final  address(es)  where  the  message  should  go  and 
reject  the  cyclic  paths.  In  this  way  we  can  encapsulate  the  routing  logic  which 
is  distributed  in  the  addresses  and  perhaps  duplicate  it  in  each  originating 
address  or  within  the  message  itself. 

When  we  have  memory  the  analysis'  becomes  more  complicated.  We  have 
to  account  for  the  interference  between  messages.  In  the  following  paragraphs 
we  will  perform  a  "best  case"  analysis.  That  is,  the  scheme  will  process  the 
messages  provided  there  is  a  way  that  they  can  proceed.  Our  approach  is  based 
on  the  observation  that  many  messages  fall  within  a  class.  Any  message  inside 
the  same  class  can  get  other  messages  moving.  Hence,  there  is  a  greater 
chance  to  have  a  desirable  sequence  of  events. 

Consider  an  addressing  scheme  with  x  ,y ,  ■  ■  ,z  addresses  without  memory 
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and  a,^,  •  •  •  <5  addresses  with  memory.  The  patterns  F(^.y)  will  qualify  the 
address  forwarding  and  the  patterns  j)  will  qualify  the  state  transitions  as 
defined  in  section  6.  To  obtain  the  different  paths  we  start  again  with  the 
source  address  o  and  we  do  a  depth  first  search  constructing  the  patterns 
Pox  -  a-  difference  is  that  once  we  arrive  at  a  memory  address  a  we 

stop.  We  obtain  in  this  way  all  paths  up  to  the  first  invocation  of  a  memory 
address. 

We  investigate  now  what  can  happen  in  a  memory  address.  Suppose  the 
address  a  appears  many  times  in  the  tree.  In  each  case  we  have  a  pattern 
Po  •  a*  intersect  these  patterns  with  the  patterns  Qai'i'J)  and  we  get  the 
patterns  which  can  get  to  a  and  change  a  from  to  sj.  We  obtain  a  bit  matrix 
Qdi^d)  with  a  "1"  in  each  case  that  there  are  some  messages  qualifying  accord¬ 
ing  to  some  Qok^ >3) Po  ■■■  a-  obtain  the  transitive  closure  Qa{i,3)  of 
Qdi'^J)-  In  the  transitive  closure  will  be  ”1”  if  a  series  of  messages 

which  could  arrive  in  a  can  get  a  from  to  state  sj.  We  have  therefore  the 
reachable  states  of  a.  We  do  this  for  each  memory  address  /3,6,  •  •  ,  etc.  A 
reachable  state  will  be  reached  only  if  the  messages  come  in  a  certain  order. 
At  this  point  we  become  optimistic.  We  assume  that  there  are  so  many  mes¬ 
sages  that  if  we  need  a  particular  order  it  will  happen. 

We  now  proceed  until  we  have  another  invocation  of  memory  addresses.  If 
the  path  up  to  here  has  an  invocation  of  the  same  memory  address  we  don't 
bother.  We  have  accounted  for  all  the  reachable  states  in  this  path.  If  not,  we 
have  to  recompute  and  possibly  augment  the  reachable  states  according  to  the 
new  path  pattern.  This  is  necessary  because  the  messages  going  down  this  path 
may  be  able  to  trigger  a  state  change  which  was  not  accounted  for  in  the  other 
paths.  The  algorithm  terminates  because  the  addresses  will  have  to  repeat  in 
long  paths.  We  don't  need  to  carry  on  after  a  repetition  because  the  same  rout- 
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ing  vrill  happen  as  in  the  previous  appearance  of  the  repeating  address. 

The  analysis  does  not  provide  the  particuleo"  state  that  a  class  of  messages 
will  exit  from  each  memory  address.  It  keeps  track,  however,  of  edl  the  possibil¬ 
ities.  When  a  message  can  go  to  edternate  paths  as  in  figure  2  the  analysis  will 
account  for  the  messages  in  both  paths  as  possibilities.  If  a  particular  path  is 
unwanted  it  has  to  be  eliminated  by  other  means  because  in  the  scheme  it  is  a 
possibility.  If  two  paths  can  be  taken  by  the  same  class  of  messages  it  is  up  to 
the  user  to  verify  that  this  is  intended  or  it  is  a  time  dependent  faulty 
behaviour. 

B.  Kxainple 

in  this  section,  we  will  Illustrate  finite  state  addressing  schemes  using  an 
example.  In  Figure  5,  we  present  mailing  addresses  and  the  instructions  han¬ 
dling  my  mail  as  they  were  effective  in  1982*.  Real  addresses  were  icorporated 
to  point  out  that  this  was  a  real  case  and  not  a  cooked  up  example.  The  mail 
routing  procedures  were  gradually  incorporated  as  new  addresses  were  intro¬ 
duced.  There  was  no  global  design  but  the  local  routing  was  defined  according 
to  reaf:onable  local  procedures.  The  address  <5  kept  mail  in  Toronto  while  I  was 
there  and  forwarded  it  according  to  a  procedure  encapsulated  by  /  as  followed 
by  my  secretary  in  Toronto.  The  same  was  happening  in  my  office  address  in 
Crete  with  my  local  secretary  following  rules  encapsulated  by  g .  A  special  mes¬ 
sage,  denoted  by  the  pattern  p,  was  switching  the  states  of  a  and  /S  in  such  a 
way  that  one  of  them  was  forwarding  while  the  other  was  retaining.  I  started 
with  receiving  mail  in  Toronto,  i.e.,  a  in  state  Sj.  "When  1  went  to  Greece  I 
entered  the  special  message  p  before  I  left  Toronto.  The  event  would  switch  a 
to  Sg  euid  then  forward  the  message  p  itself  which  would  eventually  reach  /9.  In 


•  This  should  explain  why  I  was  hard  to  reach.  Sorry! 
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this  way,  a  would  start  forwarding  and  /!?  would  start  retaining  mail.  Going  back 
to  Toronto  I  would  introduce  message  p  in  /3  and  the  situation  would  be 
reversed  and  so  on. 

Tlie  address  jol  incorporates  the  procedure  followed  by  the  superintendent 
of  my  apartment  in  Athens.  Collect  mail  in  a  batch,  in  this  example  up  to  5 
pieces,  and  then  forward  it  to  my  home  address  in  Crete.  Mail  was  routed 
according  to  four  attributes,  which  can  be  captured  by  patterns  in  the  mes¬ 
sages.  Mail  could  incorporate  the  special  message  p.  This  message  could  only 
be  generated  in  addresses  a  and  Mail  could  be  in  English  or  Greek,  it  could 
be  Business  or  Personal  and  it  could  look  Important  or  Junkmail.  Not  all 
categories  of  mail  were  generated  in  all  addresses  and  we  specify  that  in  Figure 
5.  We  will  represent  a  category  of  mail  using  four  bits  (bi,b2.^3.^4)-  The  first  bit 
specifies  the  presence  of  special  message  p,  1  means  present.  0  absent.  The 
second  bit  is  1  for  English,  0  for  Greek.  The  third  bit  is  1  for  Business,  0  for  Per¬ 
sonal.  The  fourth  bit  is  1  for  Importsint  and  0  for  Junkmail.  For  example,  the 
bit  pattern  (0.1. 1,0)  signifies  English  speaking.  Business  oriented,  Junkmail 
(there  was  a  lot  of  mail  in  that  category). 

The  figures  6a  and  6b  carry  the  analysis  as  outlined  in  section  7  for  the 
example  of  figure  5.  There  were  10  different  addresses  that  mail  could  be 
received.  Each  one  shows  as  a  different  tree,  five  in  6a  and  five  in  6b.  All  of 
these  trees  can  be  thought  of  as  connected  to  a  common  root  address  0,  the 
source  address.  The  dotted  line  indicates  the  first  invocation  of  the  memory 
addresses.  In  this  particular  example,  all  states  are  reachable  after  the  first 
invocation  of  memory  addresses.  Hence,  all  messages  which  enter  a  memory 
address  can  potentially  exit  from  any  indicated  state. 

The  trees  essentially  give  all  the  possible  routes  that  the  mail  can  take. 
For  instance,  the  first  tree  indicates  that  all  mail  received  at  the  Toronto  Per- 
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sonal  Address,  in  Knglish  of  course,  will  be  junked  if  it  is  junkmail.  The  rest 
would  exit  in  a  or  in  /3  depending  on  their  states,  i.e.,  depending  on  whether  I 
was  in  Toronto  or  in  Crete.  There  is  also  the  chance  that  it  may  circulate  for 
ever  between  a  and  /?.  This  last  case  is  worrisome.  The  reason  it  appears, 
together  with  many  similar  cycles  in  the  analysis,  is  that  it  is  a  possibility  if  the 
special  message  p  is  entered  in  the  wrong  sequence.  Consider,  for  insteince, 
the  possibility  that  I  left  Toronto  forgetting  to  enter  p.  In  Crete,  I  discover  that 
my  mail  is  still  forwarded.  1  enter,  therefore,  p  in  Crete  to  get  /?  in  sg.  In  the 
meemtime,  a  has  remained  in  Sj  keeping  mail  in  Toronto.  1  have  no  way  of 
knowing  this.  If  before  leaving  Crete  I  enter  p  again  then  1  will  get  /?  in  Sj  and  a 
in  S2.  In  this  way  both  of  the  addresses  will  be  forwarding  mail  in  a  cycle.  The 
analysis,  therefore,  points  out  a  weakness  in  the  scheme.  It  is  error  prone  if  I 
forget  the  proper  sequence  of  giving  special  instructions  for  forwarding  mes¬ 
sages.  This  can  be  remedied  by  introducing  two  different  special  messages  one 
in  a  and  another  in  /9  which  have  meaning  only  locally  and  are  not  forwarded  by 
the  mailing  procedures.*  The  analysis  can  also  point  other  shortcomings.  For 
example,  the  routing  of  junkmail  in  English  originating  in  address  h  (Athens 
office,  as  indicated  in  the  ninth  tree.  Figure  6b)  shows  that  in  this  particular 
case  junkmail  would  have  to  travel  to  North  America  to  get  junked.  This  situa¬ 
tion  can  be  remedied  by  giving  directions  in  g  to  throw  away  whatever  looks 
like  junkmail.  The  example  and  its  analysis  in  this  section  attempts  to  illus¬ 
trate  the  following  points.  First,  elaborate  addressing  schemes  are  not  only 
needed,  but  they  are  being  used.  Second,  automating  them  without  proper 
Einalysis  can  introduce  many  errors.  Third,  the  analysis  can  demonstrate  situa¬ 
tions  which  are  not  easy  to  visuedise  a  priori.  What  may  appear  as  faulty  opera¬ 
tion  in  the  analysis  may  be  tolerated  or  even  welcomed.  Finally,  small  chemges 


•This  is  actually  the  way  that  mail  was  forwarded.  The  example  was  a  slight  variation  of  the 
real  scheme. 
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may  deal  with  potential  probtems  and  make  a  scheme  less  error  sensitive  and 
more  efficient. 

9.  Conduding  remaiics 

We  have  outlined  different  kinds  of  addressing  schemes  and  investigated 
their  properties.  Addressing  schemes  constitute  a  very  important  research 
issue  in  message  systems.  We  propose  the  following  analogy.  In  file  systems 
data  are  stored  according  to  labels  and  retrieved  in  the  same  way.  In  data  base 
management  systems  data  are  retrieved  in  many  flexible  ways  in  terms  of  their 
contents  and  the  relationships  present  among  data.  It  is  this  flexibility  which 
made  data  base  management  systems  important.  In  simple  message  systems 
messages  are  delivered  to  the  receiver  address  as  specified  by  a  label.  In 
sc^histicated  message  management  systems  messages  are  delivered  according 
to  contents  and  the  relationships  among  messages  and  addresses.  We  feel  that 
powerful  addressing  schemes  will  give  message  systems  much  needed  flexibil¬ 
ity.  The  study  of  addressing  schemes  in  message  systems  is  analogous  to  the 
study  of  data  models  in  data  base  management  systems.  We  need  to  understand 
the  properties  of  addressing  schemes  before  we  can  design  advanced  message 
systems. 

We  are  also  implementing  at  the  University  of  Toronto  Imail  an  intelligent 
message  system.  The  system  will  provide  the  ability  of  specifying  message  logic 
addressing  where  routing  control  rests  with  the  messages.  We  feel  that,  in  such 
an  environment,  messages  can  be  used  not  only  to  convey  information  but  also 
to  obtain  information  To  illustrate  the  facilities  which  we  have  in  mind,  con¬ 
sider  the  following  example.  Suppose  we  want  to  find  out  who  are  the  best 
researcher’s  in  the  area  of  office  systems.  There  is  a  difficulty,  because  we  do 
not  know  the  population  of  persomwho  should  judge  them.  Choosing  the  persons 
involved  in  the  rating  may  influence  its  result.  To  deal  with  the  problem  we 
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not  know  the  population  of  person  who  should  judge  them.  Choosing  the  person 
involved  in  the  rating  may  influence  its  result.  To  deal  with  the  problem  we 
generate  an  active  message  which  does  the  following.  When  it  "eirrives''  in 
somebody's  mail  it  asks  the  person  to  mention  a  couple  of  good  reseeircher’s 
and  to  "forward"  the  message  to  other  persons  who  are  doing  work  in  the  area. 
We  have  the  words  "arrive"  and  "forward"  in  quotes  because  the  active  message 
never  arrives,  i.e.,  is  under  complete  control  of  a  user,  nor  he  forwards  it,  i.e., 
sends  it  where  he  wants.  The  message  picks  information  which  it  may  use  to 
decide  where  to  go  next  and  how  to  rate  persons.  The  message  stops  propagat¬ 
ing  when  there  are  no  new  persons  to  go  and  returns  with  its  rating  results. 
Notice  that  the  originator  has  to  specify  only  a  few  sample  recipients  at  the 
beginning.  The  rest  are  dynamically  controlled.  Notice  also  that  nobody,  reci¬ 
pient  or  sender,  can  tamper  with  the  information  the  message  gathers.  This 
example  outlines  the  capabilities  of  an  intelligent  mail  system  and  ways  that  it 
can  be  used  for  dynamic  routing  and  information  gathering.  A  message  can 
have  sufficient  logic  and  control  to  run  a  Gallup  poll  or  Delphi  experiment  by 
itself  and  return  the  results. 

Finally,  where  in  all  our  discussions  does  the  example  of  village  broadcast 
fits?  It  is  actually  a  very  general  addressing  scheme.  It  is  a  message  logic 
scheme  with  memory  and  coordination.  In  addition,  it  is  an  open  model  where 
intelligence  outside  the  addressing  scheme  can  be  used  to  route  the  messages. 
Not  bad  for  a  village  scheme!  Its  only  drawback  is  that  it  takes  considerable 
overhead  to  process  a  message.  In  the  past,  in  our  effort  to  handle  many  mes¬ 
sages  cheaply  we  had  sacrificed  flexibility.  Personal  computers  and  high 
bandwidth  networks  allow  us  to  trade  cycles  and  bandwidth  for  flexibility.  We 
would  probably  end  up  with  "messages  as  messengers"  [Yittal  81].  This  inciden¬ 
tally,  was  the  way  that  messages  were  handled  in  the  past,  when  a  king’s  mes- 
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sage  was  carried,  presented  and  identified  with  his  messenger. 
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ABSTRACT 

Message  Management  Systems  (MMS's)  ed“e  an  integration  of 
computer-based  message  systems  and  data  base  management  sys¬ 
tems.  Structure  is  imposed  on  the  messages  so  that  the  system 
can  manage  them  for  the  users.  Message  management  systems 
have  some  unique  characteristics.  We  propose  a  model  for  MMS’s. 

We  investigate  the  communication  aspects  of  the  model  and  dis¬ 
cuss  a  language  to  express  these  aspects. 

1.  Introduction 

There  is  much  emphasis  in  Office  Information  Systems  on  integration  of 
interfaces,  facilities  eind  technologies.  Two  important  functions  in  an  office 
which  need  to  be  integrated  are  the  communication  and  management  of  infor¬ 
mation.  At  present  there  are  separate  technologies  to  perform  these  functions  - 
electronic  mail  for  the  communication  and  electronic  filing  for  the  manage¬ 
ment  of  information.  Electronic  mail  is  provided  by  Computer-Based  Message 
Systems  (CBMS’s)  and  electronic  filing  is  closely  related  to  data  base  manage¬ 
ment  systems  (DBMS’s).  It  is  worthwhile  to  investigate  the  integration  of  these 
facilities. 

We  define  a  Message  Management  System  (MMS)  to  be  a  system  with  the 
capabilities  of  both  a  CBMS  and  a  DBMS.  Users  of  a  MMS  can  send  and  receive 
messages,  query  the  system  to  find  messages,  accumulate  data  from  the  mes¬ 
sages  and  specify  automatic  processing  and  routing  for  the  messages  [TsicBl]. 

We  propose  a  new  model  to  represent  these  MMS's.  The  model  represents 
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both  the  underlying  data  structures  and  the  underlying  communication  struc¬ 
ture,  and  the  operations  on  these  structures.  The  model  provides  the  MMS 
designer  with  a  language  For  describing  the  organization  and  the  communica¬ 
tion  of  information  within  the  MMS,  and  the  MMS  user  with  a  language  for  mani¬ 
pulating  the  contents  of  the  MMS. 

Current  CBMS's  provide  a  wide  range  of  services  [UhFB79].  A  model  of  a 
CBMS  consists  of  the  following  parts  [Mulv82].  The  User  Agenl  is  a  set  of 
processes  which  a  user  can  access  to  create,  present  and  store  messages.  The 
Message  Transfer  ^stem  is  an  entity  that  accepts  a  message  from  an 
originator’s  User  Agent  and  passes  it  to  each  recipient’s  User  Agent.  The  Mes¬ 
sage  Transfer  System  is  dedicated  to  the  transfer  of  messages  and  the  manage¬ 
ment  of  auxiliary  information  such  as  address  directories  and  billing  histories. 
The  Message  Transfer  System  is  further  divided  into  functional  cooperating 
components  called  Message  Transfer  Agents  which  facilitate  the  delivery.  The 
posting  slot  is  the  point  at  which  responsibility  for  a  message  passes  from  the 
originator’s  User  Agent  to  the  Message  Transfer  System.  The  delivery  slot  is  the 
point  at  which  the  Message  Transfer  System  passes  responsibility  for  a  message 
to  a  recipient's  User  Agent.  In  this  model  a  message  is  considered  to  be  com¬ 
posed  of  two  parts:  the  message  header  or  envelope  and  the  message  contents. 
The  contents  contedn  the  information  the  originator  wishes  to  send  and  the 
header  is  a  fixed  set  of  fi.elds  which  specify  the  information  required  by  the  Mes¬ 
sage  Transfer  System. 

These  models  have  some  shortcomings  for  representing  MMS’s.  They  allow 
only  a  limited  number  of  message  types,  and  message  structure  is  restricted  to 
a  uniform  set  of  fields.  A  MMS  model,  like  a  data  model,  requires  a  rich,  flexible 
and  semantically  meaningful  type  or  class  structure.  There  is  also  a  need  in  a 
MMS  to  be  able  to  exploit  the  structure  which  is  present  in  the  contents  of  the 
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mdividual  messa^^es.  Further,  CBMS  models  offer  a  limited  routing  capability. 
We  expect  a  MMS  to  be  able  to  supply  dynamic  routing  of  messages  where  the 
recipients  are  determined  and  located  based  on  the  contents  of  the  messages 
and  the  state  of  the  system.  Finally,  CBMS  models  do  not  provide  any  "message 
management"  facilities.  These  are  considered  to  be  outside  the  CBMS.  This  is 
not  the  case  with  a  MMS  and  a  model  must  reflect  this  fact. 

Data  models  used  in  DBMS’s  also  have  several  shortcomings.  First,  data 
models  supply  on  y  a  global  notion  of  data.  MMS’s  emphasize  local  data  and  the 
concept  of  ownership  of  data.  Second,  an  extremely  important  aspect  of  MMS's 
is  the  routing  of  messages  by  the  system.  Data  models  do  not  have  facilities  to 
capture  this  routing.  Also,  data  models  are  not  able  to  represent  the  target  of  a 
message,  except  perhaps  as  an  property.  Finally  MMS's  contain  a  lot  of  activity: 
what  the  actions  are  and  v/here  they  take  place  are  very  important  properties 
that  must  be  mocelled.  Data  models  empasize  structure  and  relationships,  not 
actions.  In  addition,  data  models  can  not  represent  the  fact  that  some  of  the 
relationships  and  actions  in  a  MMS  are  dependant  upon  the  location  of  the  data. 

2.  Model  Outline 

We  model  al'  actions  in  a  MMS  as  operations  on  a  communication  base 
which  is  the  repontory  of  all  messages  [TsicBl].  A  message  is  the  basic  unit  of 
communication.  .Agents,  wliich  can  be  users  or  processes  acting  on  the  users* 
behalf,  comrnunii^ate  by  placing  messages  in  the  communication  base.  In  addi¬ 
tion  to  acting  as  a  medium  of  communication,  the  communication  base  can 
retain  some  or  al'  of  the  information  for  future  use. 

The  agents  are  outside  the  model.  They  interact  with  the  communication 
base  when  they  take  on,  or  "play"  .  one  of  the  designated  roles  in  the  system.  An 
agent  can  play  several  roles  (but  only  one  at  a  time)  and  a  role  can  be  played  by 
several  agents.  We  assume  there  is  some  authorization  mechanism  outside  the 
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model  to  decide  the  roles  a  particular  agent  is  entitled  to  play. 

Wee  define  a  role  to  be  a  uniquely  identifiable  entity  within  an  office  or 
organization  that  sends  or  receives  information.  In  particular,  a  role  can 
correspond  to  a  person  -  every  user  plays  the  role  of  him/herself;  to  a  group, 
such  as  "Students”  or  "Employees";  to  an  office  function,  which  is  a  definable 
set  of  responsibilities  and  actions  within  an  office  or  organization,  for  example 
"Sales  Manager"  or  "Instructor  of  CSC434",  or  to  a  "system  server"  which 
represents  entities  such  as  printers,  file  servers  or  a  waste  basket  for  discarded 
messages. 

Each  role  has  access  to  a  subset  of  the  messages  in  the  communication 
base,  namely  those  owned  by,  or  local  to,  the  role.  By  playing  a  role  an  agent 
gains  .access  to  its  local  messages.  We  may  also  place  constraints  on  a  role’s 
access  by  restricting  the  operations  it  is  allowed  to  perform  and  the  types  of 
messages  it  is  allowed  to  own.  We  identify  three  cases  of  ownership  within  a 
MMS.  If  a  message  is  associated  with  a  single  role  we  say  that  the  ownership  is 
private.  If  a  message  is  associated  with  two  or  more  roles  we  say  that  the  owner¬ 
ship  is  shared.  In  this  case  there  is  one  "logical"  message  and  the  changes  made 
by  any  of  the  roles  are  automatically  visible  to  all  the  other  owners.  The  final 
case  is  called  corrimon  ownership.  Independent  copies,  i.e.  the  seime  contents 
but  different  identifiers,  are  associated  with  two  or  more  roles  and  the  changes 
made  by  any  of  the  roles  apply  only  to  their  own  copies. 

A  role  gains  ownership  of  a  message  when  it  inserts  a  new  message  into  the 
communication  base  or  when  it  receives  a  new  message.  In  the  second  case  the 
role  is  designated  by  another  role  to  share  the  ownership  of  the  message.  Impli¬ 
citly,  a  role  can  gain  ownership  when  an  "inferior"  role  gels  a  new  message. 
The  concept  of  inferior  (superior)  roles  is  used  to  express  relationships  among 
roles.  For  example,  a  manager  may  wish  to  have  access  to  some  of  the  mes- 
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sages  of  the  employees  under  him. 

A  messt\go  consists  of  a  syslem-wide  identifier  and  some  contents.  A  mes¬ 
sage  can  be  optionally  typed.  A  number  of  message  type  categories  can  be 
defined  and  a  message  declared  to  be  of  a  type  within  a  certain  category.  The 
message  will  then  inherit  the  structure,  constraints  and  operations  of  the 
category.  The  type  of  a  message  can  also  be  specified  on  the  hy  when  a  message 
is  created.  In  such  a  case  the  structure  has  to  be  communicated  together  with 
the  message.  The  structure  of  a  message  can  be  dynamic  and  change  as  the 
message  is  communicated  to  new  roles.  The  definition  of  a  message  type  allows 
us  to  capture  the  fact  that  a  lot  of  the  communication  in  an  office  can  be 
grouped  into  sets  with  similar  properties  and  eu'e  usually  processed  in  an  identi¬ 
cal  manner. 

The  contents  of  a  message  are  subject  to  change,  even  a  change  of  format, 
so  there  is  no  content  value(s)  stable  enough  to  uniquely  identify  a  message.  By 
creating  an  identifier  outside  the  reach  of  the  agents  we  can  always  isolate  a 
particular  message  instance. 

The  message  definition  within  our  model  is  based  on  an  "object-oriented” 
approach  and  the  use  of  abstraction  mechanisms  from  semantic  data  model¬ 
ling.  With  an  object-oriented  approach,  we  define  a  set  of  types  or  classes.  Each 
message  is  considered  an  instance  of  a  type  and  so  inherits  the  structure,  con¬ 
straints  and  operations  of  that  type.  A  message  type  is  defined  by  specifying  the 
properties  of  its  instances. 

Different  message  types  may  be  related  by  the  is- a  relationship  [MyBWBO]. 
Given  two  message  types  P  and  Q,  we  say  P  “is-a  Q  if  every  instance  of  P  is  also 
an  instance  of  Q.  The  message  type  P  is  said  to  be  a  speciaLization  of  Q  (con¬ 
versely  Q  is  a  generalization  of  P)  and  may  contain  additional  properties  to 
those  of  Q.  This  type  interconnection  allows  us  to  represent  the  message 
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categorles  and  the  inheritence  of  properties.  It  also  allows  messages  to  change 
their  types  (actually  the  interpretation  placed  on  the  messages  by  the  roles 
changes).  These  changes  are  restricted  to  paths  through  the  hierarchy.  A  mes¬ 
sage  can  be  considered  an  instance  of  another  connected  type  as  long  as  it  has 
the  required  properties.  Thus  type  changes  are  limited  to  paths  in  the  is-a 
hierarchy. 

Each  message  type  can  be  further  characterized  as  simple  or  aggregate 
[GibbBS].  Aggregate  messages  may  "contain"  other  messages.  Containment  is 
expressed  using  the  part-o/ relationship,  eg.  we  say  xpart-of  y  if  y  contains  x. 
Tliis  mechanism  is  useful  for  representing  such  things  as  dossiers,  multi-part 
forms  or  several  documents  "stapled"  together.  "We  require  that  these  aggregate 
messages  have  their  own  unique  identifiers  separate  from  their  constituents’ 
identifiers. 

The  operations  available  from  the  model  provide  both  management  and 
communication  capabilities.  The  operations  are  initiated  by  a  role.  The  role 
supplies  the  context  for  the  operation.  The  create  operation  places  a  new  mes¬ 
sage  into  the  communication  base  and  it  is  owned  by  the  role  performing  the 
operation.  Property  values  can  be  supplied  at  creation  time  or  later  via  the 
"modify"  operation.  The  identifier  is  always  system-supplied  at  creation  time. 
The  modify  operation  alters  the  contents  of  an  existing  message.  The  identifier 
cannot  be  modified.  The  delete  operation  hais  two  cases.  First,  if  ownership  of 
the  message  is  shared,  then  only  the  role  issuing  the  delete  loses  ownership  of 
the  message.  Second,  if  ownership  is  private,  then  the  message  is  removed  from 
the  communication  base.  The  select  operation  retrieves  one  or  more  messages 
from  the  local  message  set  of  the  role.  The  select  can  specify  a  message 
identifier  or  some  qualification  on  the  content  properties  of  the  messages 
desired.  A  copy  operation  creates  a  new  message  with  a  new  identifier  but  the 
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same  contents  and  type  as  somti  specified  message,  'f’hc  copy  is  owned  by  the 
role  that  issued  the  command.  A.  send  operation  shares  ownership  of  some 
specified  message  with  the  set  of  "destination"  roles.  This  set  of  destinations  is 
determined  by  the  addressing  scheme  for  the  MMS.  We  assume  ownership  is  still 
shared  by  the  sender.  A  transfer  can  be  accomplished  by  a  send  and  delete. 

Finally  we  provide  two  operations  to  manipulate  an  aggregate  message.  The 
put  operation  adds  a  constituent  to  an  existing  aggregate.  The  get  operation 
removes  a  constituent  from  an  existing  ciggregate.  Ownership  of  an  aggregate 
implies  ownership  of  each  of  the  constituents  and  the  get  places  the  consti¬ 
tuent  in  the  role’s  local  message  set  as  an  independant  entity.  We  cannot  delete 
a  constituent  until  it  is  removed  from  an  aggregate  (analogous  to  removing  a 
document  from  a  folder  before  throwing  it  out)  and  we  cannot  delete  an  aggre¬ 
gate  unless  it  is  empty. 

3.  Conimunication  in  the  Model 

We  must  also  deserri’oe  how  messages  circulate  within  an  MMS,  i.e.  how  the 
scopes  of  the  messages  in  tl  e  communication  base  are  determined  [Tsic83].  We 
view  the  communication  base  as  being  supported  by  a  logical  network  (see  Fig¬ 
ure  1)  that  is  transparent  to  the  agent.  We  call  the  nodes  of  the  network 
addresses.  An  address  is  a  logical  unit  that  provides  a  notion  of  context.  All 
routing  processing,  queueing  of  received  (but  not  yet  processed)  messages  and 
storing  of  accepted  messages  is  performed  loced  to  an  address.  Each  address  is 
uniquely  identified.  TTie  communication  between  addresses  assumes  reliable 
process-to-process  connections  as  provided  by  the  session  layer  of  the  ISO 
Reference  Model  [TancBlJ.  Our  model  divides  the  application  layer  into  address 
and  role  sublayers. 

There  are  two  kinds  of  addresses:  routing  addresses  and  mail  addresses. 
Routing  addresses  can  never  originate  or  keep  messages,  only  forward  them. 
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Fi9ure  1:  Conmun  i cat  i on  in  the  f1H5  Model 
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Mail  addresses  can  originate  and  keep  messages  as  well  as  forward  them. The 
routing  addresses  provide  flexibility  in  the  evaluation  of  the  scope.  Mail 
addresses  are  the  targets  of  messages.  Each  mail  address  corresponds  to  a 
role-agent  pair.  Messages  sent  to  a  particular  role  are  logically  routed  to  the 
set  of  mail  addresses  that  correspond  to  all  the  agents  playing  that  role. 

We  believe  that  the  role  -  address  relationship  provides  the  flexibility 
needed  for  a  MMS.  A  role  defines  the  access  for  an  agent  playing  the  role  and 
also  provides  security  in  that  roles  are  predefined.  The  messages  available  are 
those  owned  by  the  role  and  those  ov^ned  by  "inferior"  roles.  An  address  defines 
a  logical  location  in  the  MMS.  So  a  role  links  agents  with  locations. 

The  network  of  addresses  is  defined  by  the  set  of  connections  for  each 
address.  Given  two  addresses  A  and  B,  we  say  A  connected  io  B  if  A  knows  about 
B  and  is  able  to  send  messages  to  it.  We  assume  the  connections  are  directed. 

A  set  of  primitive  operations  are  used  to  circulate  messages.  Tiie  routing 
of  a  message  from  its  origin  to  its  destinations  cam  be  expressed  in  terms  of 
these  primitives.  They  are  not  available  to  the  roles  but  initiated  when  a  send 
commamd  is  issued. 

An  address  originates  a  message  when  the  message  is  placed  into  circula¬ 
tion  local  to  that  address.  Tliis  is  the  first  circulation  operation  caused  by  a 
send.  A  message  can  originate  from  only  one  address  each  time  it  is  placed  into 
circulation.  An  address  cd.n  forward  a  message  to  another  address  connected  to 
it.  The  first  address  transfers  the  message  to  the  second  and  loses  all  contact 
with  it.  An  address  can  share  a  message  with  another  address  connected  to  it.  In 
this  case  the  first  address  retains  the  message  as  well  as  transferring  it.  This 
situation  would  not  be  possible  in  a  paper  office  but  is  realistic  with  electronic 
mail.  An  address  can  accept  a  message  which  we  interpret  as  the  message 
reaching  one  of  its  targets  and  leaving  circulation  at  that  point  along  the 
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particular  path  (a  message  can  travel  several  paths  of  the  network  simultane¬ 
ously).  Thus  this  address  is  considered  part  of  the  scope  of  the  message  and  its 
associated  role  obtains  ownership  of  the  message.  Finally  an  address  can  drop  a 
message  which  means  the  message  leaves  circulation  without  reaching  one  of 
its  destinations. 

An  addressing  scheme  is  a  way  of  specifying  and  interpreting  information 
on  messages  that  eventually  brings  them  to  the  attention  of  the  proper  reci¬ 
pients.  The  main  objects  of  an  addressing  scheme  are  messages,  addresses  and 
the  network  that  defines  the  addresses’  connectivity. 

We  categorize  addressing  schemes  according  to  where  the  routing  pro¬ 
cedures  reside  [Tsic83].  In  an  address  logic  scheme  messages  are  completely 
passive.  'The  routing  procedures  are  associated  with  the  addresses.  'The  logic 
present  in  each  address  decides  whether  it  should  keep  a  received  message, 
where  it  should  forward  the  message  and  whether  it  will  change  any  values  on 
the  message.  In  a  message  Logic  scheme  the  routing  procedures  are  associated 
with  the  messages.  When  a  message  arrives  it  obtains  the  address  identification 
and  has  access  to  the  information  stored  in  the  address.  The  message  itself 
decides  whether  it  should  leave  a  copy,  to  what  addresses  it  should  go  next  eind 
whether  it  should  retain  some  of  the  information  available  to  it. 

Two  other  aspects  of  addressing  schemes  that  have  to  do  with  the  inter¬ 
dependence  of  messages  are  memory  and  coordination.  An  addressing  scheme 
will  be  called  memoryless  if  am  address  does  not  remember  anything  about  the 
messages  which  have  previously  passed  by.  including  those  messages  accepted. 
An  addressing  scheme  will  be  called  coordination  free  if  it  processes  each  mes¬ 
sage  separately  without  reference  to  other  messages  which  may  be  waiting  for 
processing  at  the  same  address. 

We  define  a  single  execution  of  a  routing  policy  to  be  the  processing  of  a 
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single  message,  i.e.  all  the  actions  taken  against  the  message  at  all  the 
addresses  it  visits  from  the  time  it  enters  circulation  until  the  time  it  leaves. 
We  say  the  routing  of  a  message  is  complete  if  its  execution  halts,  i.e.  the  mes¬ 
sage  leaves  circulation  by  being  accepted  at  one  or  more  of  the  addresses  it 
visits.  A  routing  policy  is  complete  if  the  routing  for  every  message  is  complete. 

For  the  remainder  of  this  section  we  assume  an  address  logic  scheme 
unless  otherwise  stated.  We  let  E{m)  =  Pi{m) . -Pkim)  represent  the  execu¬ 

tion  of  some  routing  policy  for  a  particular  message  m.  During  the  execution  m 
visits  the  set  of  addresses  .  .  .  ,a^j  and  their  corresponding  routing  pro¬ 
cedures  are  executed.  Since  these  procedures  are  at  different  addresses  they 
may  execute  concurrently.  In  order  to  talk  about  the  overall  effect  an  execu¬ 
tion  has  on  the  state  of  the  addressing  scheme  we  introduce  a  notion  of  serial- 
izability  similar  to  that  in  distributed  databases  [BeGoSO]. 

We  first  discuss  the  equivalence  of  executions.  The  ultimate  result  of  an 
execution  E{m)  is  to  move  m  through  the  network  of  addresses.  This  can  be 
conveniently  represented  as  a  visit  tree  which  we  construct  as  follows: 

(1)  the  root  of  the  visit  tree  is  the  originating  address; 

(2)  if  m  is  moved  from  address  a  to  address  b  during  E{m)  then  a  node 
labelled  ”b"  is  made  a  child  of  the  node  labelled  "a”  and  an  arc  drawn  to 
connect  them  (an  address  may  appear  in  more  than  one  node  in  a  tree). 

We  say  that  executions  of  two  routing  policies  for  a  message  m  are  computa- 
tioTiaLLy  equivalent  if  they  produce  the  same  visit  trees.  Not  only  must  the  same 
addresses  be  visited  but  the  same  paths  through  the  addresses  must  be  fol¬ 
lowed. 

We  say  an  execution  is  serial  if  no  procedures  execute  concurrently,  i.e. 
each  procedure  executes  to  completion  before  the  next  one  begins.  Also,  an 
execution  is  serializable  if  it  is  computationally  equivalent  to  a  serial 
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execution. 

Observxitumiln  a  memoryless,  coordination-free  address  logic  scheme,  the  exe¬ 
cution  of  its  routing  policy  for  any  message  m  is  serializable. 

The  proof  of  this  observation  is  by  induction  on  the  depth  of  the  visit  tree  pro¬ 
duced  by  E{Tn).  The  restrictions  that  the  scheme  be  memory-less  and 
coordination-free  are  important.  They  ensure  that  executions  for  different  mes¬ 
sages  have  no  effect  on  each  other.  Similar  arguments  can  be  used  to  show  the 
same  property  is  true  of  memoryless,  coordination-free  message  logic  schemes 
so  we  obtain  the  more  general  result  that  executions  for  all  memoryless, 
coordination-free  addressing  schemes  are  serieJizable.  The  investigation  of  seri- 
alizability  for  addressing  schemes  with  memory  and  coordination  is  a  much 
more  difficult  and  interesting  problem. 

ObservaJbicm.ll  A  is  a  memoryless,  coordination-free  addressing  scheme,  then  A 
is  complete  if  the  following  conditions  hold 

(1)  all  routing  procedures  Pi,  .  .  ,  ,F„  are  written  in  a  language  that  con¬ 
tains  the  usual  expression  syntax,  assignment  statements,  the  routing 
primitives,  bounded  loop  statements  and  IF-THEN-EISE  statements,  but  no 
GOTO  statements; 

(2)  all  medl  addresses  can  recognize  the  messages  they  originate  using 
just  Pi  and  the  information  in  the  message; 

(3)  the  connectivity  of  the  network  is  such  that  any  address  has  at  most 
one  edge  leading  into  it. 

To  prove  this  observation  we  note  that  a  memoryless,  coordination-free 
addressing  scheme  is  complete  if  (a)  every  routing  procedure  Pi  halts  and  pro¬ 
duces  a  change  of  state  for  every  received  message,  and  (b)  there  are  no  loops 
in  any  of  the  paths  followed  by  a  message.  Routing  procedures  written  in  the 
specified  language  can  be  mapped  to  primitive  recursive  functions  and  so 
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guaranteed  to  halt.  The  last  two  conditions  of  the  observation  can  be  shown  to 
ensure  that  there  are  no  loops  in  any  of  the  paths  that  can  be  followed  by  a 
message. 

4.  RoutiDg  Semantics 

The  semantics  of  the  routing  specification  language  is  expressed  using  the 
actor  model  of  computation  [Grei75].  Actors  have  several  properties  which 
relate  well  to  parallel  processing,  an  integral  part  of  communication  in  a  MMS. 
A  single  sequential  process  is  represented  by  a  totally  ordered  set  of  events. 
Systems  of  parallel  processes  are  represented  by  partially  ordered  sets  of 
events.  These  ordered  sets  of  events  are  the  behaviours  of  the  systems.  Events 
represent  the  receiving  of  a  request  by  an  actor. 

Individual  actors  are  specified  by  causal  axioms  which  are  properties  that 
will  hold  for  any  behaviour  of  an  actor  system  that  contains  the  particuleir 
actor.  They  specify  relations  among  events.  These  relations  are  then  the  pro¬ 
perties  of  the  behaviours  as  partial  orders. 

An  alternative  formalism  to  actors  is  Petri  nets.  They  have  been  used  to 
model  systems  where  communication  is  involved,  such  as  protocols  [Merl79] 
and  user-system  dialogues  [Barr83].  But  in  all  these  cases  they  must  be 
extended  in  some  way.  Petri  nets  are  based  on  state  changes  and  so  we  have  the 
problem  of  reconciling  local  and  global  state  changes  and  references.  Finite 
state  machines  are  another  formalism  used  to  model  such  things  as  protocols 
[Merl79].  They  have  the  same  local-global  state  problems  as  Petri  nets.  They 
also  are  not  as  good  as  a  descriptive  tool  as  actors  though  perhaps  better  for 
analysis. 

We  call  our  actor-based  formalism  message  transfer  semantics.  The  funda¬ 
mental  action  within  an  addressing  scheme  is  the  transfer  of  a  message  from 
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one  address  to  another  along  a  connection  in  the  network.  The  routing  of  a 
message  is  just  a  series  of  these  transfers.  We  can  impose  partial  orderings  on 
the  transfers  which  determine  the  paths  the  routing  takes  within  the  network. 
When  a  message  arrives  at  an  address  it  will  cause  zero  or  more  transfers  to  a 
subset  of  that  addresses  connections.  So  we  can  express  the  routings  as  a  series 
of  tramstfers  and  the  causal  relations  between  them.  This  is  analogous  to  the 
specification  of  the  behaviour  of  an  actor  system. 

Besides  the  object  types  message  and  address  we  define  an  envelope  object 
type.  An  envelope  always  accompanies  a  messeige  in  any  routing  and  is  used  to 
maintain  "routing-dependant"  information  such  as  the  origin  of  the  message, 
the  destination  addresses  or  even  the  path  of  addresses  the  message  is  to  fol¬ 
low.  The  envelope  is  separate  from  the  contents  of  the  message  and  exists  only 
while  the  message  is  in  circulation.  Each  time  a  message  is  put  into  circulation 
it  gets  a  new  envelope.  The  envelope-message  pair  is  similar  to  the  "package" 
concept  for  actors  described  in  [Hewi77], 

We  define  a  message  transfer  to  be  a  tuple  <t,e,7n,p,s>  where  t  is  the  target 
address  of  the  transfer,  e  is  the  envelope,  m  is  the  message,  p  is  the  path 
number  and  s  is  the  step  number  in  the  path.  We  assume  the  path  numbers 
within  a  routing  are  all  different  so  a  given  path  number  can  not  refer  to  more 
than  one  path  taken  by  a  particular  message  during  a  particular  execution  of  a 
routing  policy. 

For  any  pathp,  if  Si<s2  then 

<t  i,e  .m  ,p  ,s  -*  <f2,G,m,p.Sg>. 

The  ordering  "->"  is  referred  to  as  the  path  ordering.  Path  orderings  for  all 
paths  form  a  partied  order  on  all  transfers  in  a  routing.  The  same  symbol  "->"  is 
used  to  denote  the  transitive  closure  of  the  union  of  the  total  orderings  for 
each  individual  path  and  the  relations  between  transfers  of  different  paths  due 
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to  the  initiation  of  a  new  path.  For  example,  if  the  arrival  of  message  m  at 
address  aj  caused  the  transfer  of  m  to  both  ag  and  ag  then  we  would  write 

<ai,e  ,m,pi,s>  *  <03,6  ,m .p2.0>  <aQ,e  ,m,pg,0>. 

The  information  present  in  a  message,  envelope  or  address  can  play  a  role 
in  determining  the  transfers  caused  by  an  eirrival.  An  arrival  could  also  cause 
some  of  the  information  to  be  changed.  If  we  limit  our  concern  to  what  are  the 
values  of  particular  properties  then  we  can  represent  these  "state  axioms"  as 
tuples  <o,p,v>  where  0  is  the  object,  p  is  a.  property  of  0  and  v  is  the  current 
value  of  p  which  can  be  single  or  multi-valued.  This  representation  is  a  prag¬ 
matic  one.  We  could  represent  the  local  states  of  objects  as  actor  systems  but 
our  restricted  use  does  not  seem  to  warrant  it. 

We  con  now  place  constraints  on  the  routing  behaviour  by  associating  state 
axioms  with  the  causal  expressions.  For  example  if  we  only  wanted  to  send  a 
message  m  to  address  from  address  ao  if  a  particular  property  p  of  m  has 
value  V,  we  would  write 

<m,p,v>  <aQ,e,m,p,s>  -»  <0^,6  ,m,p  ,s'>. 

We  assume  only  the  appropriate  transfers  will  occur  from  a  set  of  axioms. 

Message  transfer  semantics  provides  a  formal  expression  of  the  behaviour 
of  any  routing  policy  specified  in  our  model.  This  allows  us  to  compare  different 
policies,  and  even  different  categories  of  addressing  schemes,  and  determines  if 
they  are  equivalent  (in  the  sense  that  they  deliver  the  same  set  of  messages  to 
the  same  recipients). 

5.  Conclusions 

We  have  described  a  model  of  communication  in  a  message  management 
system.  This  model  provides  a  framework  for  the  design  and  implementation  of 


a  MMS. 
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We  discuss  a  scheme  for  viewing  communication  within  a  MMS  that  can  be 
used  to  define  properties  such  as  serializability  and  completeness. 

We  introduce  the  message  transfer  semantics  that  can  be  used  to  give  a 
formal  meaning  to  message  routing.  These  semantics  give  us  a  way  of  compar¬ 
ing  routing  policies  and  to  transform  and  optimize  routing  policies  while  ensur¬ 
ing  equivalent  behaviour. 

Our  MMS  model  represents  the  notion  of  the  scope  of  a  message.  In  CBMS's, 
messages  usually  have  a  well-defined  target.  But  target  has  a  temporary  nature 
in  that  once  a  message  is  delivered  it  loses  its  significance.  A  MMS,  because  of 
its  data  base  side,  has  a  more  permanent  nature.  Messages  are  both  communi¬ 
cated  and  stored.  Thus  the  scope  of  a  message  has  an  existence  past  the 
delivery  of  a  message.  To  ensure  flexibility  we  allow  the  scope  of  a  message  to 
be  dynamically  evaluated  based  on  the  contents  of  the  message  and  the  state  of 
the  system. 

In  our  MMS  model  we  use  the  notion  of  logical  address  and  role  to  provide  a 
flexible  binding  between  user  and  physical  location.  More  than  one  address  can 
be  associated  with  a  physical  location  and  an  address  can  be  associated  with 
several  physical  locations.  The  bindings  between  users  and  addresses,  and 
addresses  and  physical  locations  is  very  dynamic. 

The  MMS  model  represents  the  notion  of  ownership.  In  a  CBMS  the  sender 
initially  owns  a  message  and  transfers  the  ownership  to  the  receiver.  In  a  DBMS 
information  is  owned  by  the  data  base  which  allows  access  to  the  users.  A  MMS 
is  closer  to  a  CBMS  in  that  we  view  messages  as  being  owned  by,  or  local  to,  par¬ 
ticular  roles  but  we  allow  the  notion  of  "shared"  or  "common"  ownership  of  a 
message  among  several  roles.  Within  this  framework  the  global  view  of  a  DBMS 
is  a  special  case. 
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Our  MMS  model  provides  abstraction  mechanisms.  Generalization,  aggrega¬ 
tion  .and  classification  are  suitable  for  defining  message  types  or  classes  similar 
to  the  data  classes  of  the  semantic  data  models.  Cover  aggregation  could  be 
used  to  define  such  things  as  dossiers  which  could  be  part  of  our  model 
[Gibb82]. 

Finally,  our  model  provides  operations  from  both  the  CBMS  and  the  DBMS. 
Users  are  able  to  send,  receive,  acknowledge  and  reply  to  messages  as  well  as 
retrieve,  create,  insert,  delete  and  modify  messages. 
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A  Data  Modelling  Approach  for  Office  InfonnatiDn  Systems 
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Simon  Gibbs  and  Dennis  Tsichritzis 


Mistract  A  data  model  for  representing  the  structure  and  semantics  of  office  objects 
is  proposed.  The  model  contains  features  for  modelling  forms,  documents  and  other 
complex  objects;  these  features  include  a  constraint  mechanism  based  on  triggers, 
templates  for  presenting  objects  in  different  media,  and  unformatted  data  types  such 
as  text  and  audio.  The  representation  of  common  office  objects  is  described.  User- 
level  commands  may  be  translated  to  operations  within  the  model. 

Categories  and  Subject  Descriptors:  H.1.2[ Models  and  Principles]:  User/Machine 
Systems— human  information  processing,  H.  2.1  [Database  Management]:  Logical 
Design— dafa  models',  H. 4. 1  [Information  Systems  Applications]:  Office  Automation 

General  Term:  Data  Models 

Additional  Key^fords  and  Phrases:  Templates,  unformatted  data 


1  Introduction 


A  data  model  is  a  specification  language  for  representations  of  the  real  world. 
An  implementation  of  a  data  model,  a  database  management  system,  is  a  powerful  tool 
for  applications  with  large  amounts  of  persistent  and  inter-related  data. 

This  paper  discusses  a  data  model  designed  specifically  for  the  office  environ¬ 
ment.  In  addition  to  aiding  in  the  management  of  data,  data  models  promote  extensi¬ 
bility  and  software  integration  by  separating  the  specification  of  the  logical  structure 
of  data  from  the  programs  accessing  the  data.  Furthermore,  by  formulating  a  descrip¬ 
tion  of  the  office  in  data  modelling  terms,  it  is  possible  to  use  many  of  the  techniques 
and  results  from  database  research.  Finally,  data  model  operations  can  be  used  as  a 
set  of  primitives  by  systems  dealing  with  the  higher-level  problems  of  organizations 
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and  individuals  --  their  goals,  actions  and  intentions 


A  lar’gc  number  of  data  niodfds  have  bc'cn  proposed  ['3d],  yet  earlier  models  do 
not  completely  satisfy  the  requirements  of  the  office  domain.  These  requirements 
are: 

•  conceptual  structure 

The  structures  supported  by  the  model  should  correspond  to  the  concepts  of 
the  user.  In  particular  the  model  should  have  the  notion  of  objects,  that  is, 
interned  structures  which  map  in  a  1-1  fashion  to  real-world  entities.  Similarly, 
operations  within  the  model  should  be  capable  of  capturing  the  behavior  of 
such  common  office  activities  as  filing  and  retrieval,  mailing,  and  document 
preparation. 

•unformatted  data 

The  model  should  handle  both  traditional  formatted  data  (integers,  fixed-length 
strings,  etc.)  and  unformatted  data  such  as  text  or  audio. 

•  presentation 

The  model  should  distinguish  between  an  internal,  structural  representation 
suitable  for  processing  and  an  external  representation  which  is  more  appropri¬ 
ate  for  the  user.  The  realization  of  an  object  using  an  external  representation 
in  a  particular  medium  is  known  as  presentation. 

Conceptual  structure  is  a  traditional  concern  within  data  modelling  [1],  and  the  addi¬ 
tion  of  unformatted  data  is  currently  being  addressed  [6.  25,  31].  The  third  require¬ 
ment  is  treated  in  some  forms  data  models  [20,  33]  and  is  also  related  to  the  problem 
of  text  formatting  [7].  In  general,  though,  there  is  no  single  data  model  that  fulfills  all 
three  requirements.  The  office  data  model  presented  in  this  paper  attempts  to  over¬ 
come  these  deficiencies  by  unifying  features  from  the  fields  of  conceptual  modelling, 
unformatted  data  management,  and  text  formatting. 


The  remainder  of  the  paper  is  organized  as  follows  Section  2  gives  an  overview 
of  the  basic  structures  and  operations  within  the  data  model.  The  features  intended 
specifically  for  the  office  environment  are  presented  in  Section  3.  In  Section  4  we  use 
the  model  to  represent  common  objects  and  operations  within  the  office.  Section  5 
contains  a  brief  summary  and  critique  of  the  office  data  model. 
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2  The  Model' 


2. 1  Object  Types 


The  office  data  model  uses  the  concepts  of  object  type  and  object,  as  proposed  in 
[26],  to  organize  its  representations  of  the  real  world.  An  object  type  is  the  structural 
specification  of  a  class  of  objects.  A  member  of  such  a  class  is  referred  to  as  an  in¬ 
stance  of  the  object  type.  For  example,  we  can  define  the  object  type  Person  as 


define  object  type  Person  begin 
I**operties: 

Person  ->  Name,  Address,  TeLephQne+\ 

constraints; 

data  t3rpe  of  Name  is  string{'2>0)\ 
data  type  of  Address  is  string (QO)-, 
datatype  of  Telephone  is  string{12)-, 
{Name,  Address)  is  unique; 


end 


Here  Person  has  the  three  properties;  Name,  Address,  Telephone.  Both  Name  and  Ad¬ 
dress  are  single  valued  while  Telephone  is  multivalued  (this  is  indicated  by  the  ’  +  ’  fol¬ 
lowing  Telephone).  The  constraints  section  identifies  the  data  types  of  property  values 
emd  indicates  that  no  two  instances  of  Person  may  agree  on  both  Name  and  Address, 

The  properties  of  an  object  type  can  be  hierarchically  decomposed.  As  an  ex¬ 
ample,  in  the  definition 

define  object  type  Employee  begin 
iwoperties: 

Employee  Hilary,  Scill-^-, 

Skill  -»  Job  Category,  Years  Experience', 

end 

Skill  has  the  two  sub-properties  JobCategory  and  Years Elxperience. 

'  A  formal  syntax  and  semantics  specification  is  in  preparation  [10]. 
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Object  types  may  be  related  by  specialization  and  generalization  [22,  29].  For 


example,  if  we  add  the  statement 


Employee  is-a  Person', 

then  Employee  becomes  a  specialization  of  Person.  Instances  of  Employee  will  also  be¬ 
long  to  Person  and  so  inherit  the  property  structure  of  Person.  The  only  restriction 
on  specialization  is  that  the  is-a  relationships  form  an  acyclic  digraph. 

The  above  examples  have  Illustrated  how  an  object  may  be  viewed  as  an  aggre¬ 
gate  of  property  values.  It  is  also  possible  to  decompose  an  object  into  other,  consti¬ 
tuent,  objects.  (This  is  referred  to  as  grouping  [13]  or  cover  aggregation  [4]  in  the 
data  modelling  literature.)  As  an  example,  consider  the  Department  object  type  in 
which  we  need  to  represent  the  association  between  departments,  managers  and  staff. 


define  object  type  Department  begin 
properties: 

Department  -»  Title, 
constituents: 

Department  ^  Manager,  Staff 
mappings 

^aff  '.Managed&y  -»  Manager-, 
Manager:  Of  Dept  >  Department, 
Manager:  Of  Staff  -»  Staff', 
constraints; 

object  type  of  Manager  is  Employee', 
object  type  of  Staff  is  Employee, 


end 


For  a  particular  Department  instance  the  value  of  the  Manager  constituent  will  be  a 
single  Employee  object  and  the  value  of  the  Staff  constituent  will  be  a  set  of  Employee 
objects.  Both  Manager  and  Staff  can  be  constrained  to  be  unique,  i.e..  each  depart¬ 
ment  would  then  have  a  separate  manager  and  an  employee  could  belong  to  the  staff 
of  at  most  one  department.  The  mappings  section  defines  three  mappings:  Managed- 
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By,  OfDept,  and  OfStaff.  In  a  mapping  definition,  the  mapping  name  appears  to  the 
right  of  the  'argument'.  So,  for  instance,  the  Of  Staff  mapping  when  applied  to  a 
Manager  of  a  Department,  evaluates  to  the  value  of  Staff  for  that  Department 

Mapping  names,  constituent  names,  and  property  names  can  be  concatenated 
to  form  a  chain.  Chaining  is  derived  from  database  query  languages  such  as  CABLE 
[28],  and  is  comparable  to  the  use  of  functional  composition  in  DAPLEX  [27],  A  chain 
may  be  thought  of  as  a  'path'  through  the  data  space.  Chains  are  either  bound  or  un¬ 
bound.  An  unbound  chain  has  no  explicit  starting  point  indicated.  In  contrast,  a 
bound  chain  is  anchored  to  a  specific  object  and  can  be  evaluated.  As  examples  of 
bound  chains,  suppose  we  have  an  instance  of  Employee  identified  by  John.  The  follow¬ 
ing  are  bound  chains  anchored  lojohn. 

John.  Name 

john:ManagedBy:OfDept.  Title 

Chains  are  evaluated  left  to  right.  So,  the  first  example  refers  to  John's  name  and  the 
second  to  the  title  of  the  depeirtment  of  the  manager  oijohn. 

2.2  Object  Operations 

The  model  provides  a  small  number  of  operations  for  modifying  the  data  space. 
The  create  operation  creates  a  new  instance  of  an  object  type  and  binds  the  object  to 
an  identifier,  the  object  may  be  removed  with  the  destroy  operation.  The  copy  opera¬ 
tion  creates  an  object  with  the  same  property  values  as  an  existing  object.  The  assert 
and  remove  operations  alter  the  property  and  constituent  values  of  an  object. 
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Four  operations  are  associated  with  transactions  [11]:  tbegin,  tend,  and 

export.  A  tbegin  initiates  a  transaction  which  may  then  be  aborted  by  the  abort  opera¬ 
tion  or  committed  by  tend.  Failure  occurs  automatically  when  uniqueness  constraints 
remain  violated  upon  reaching  a  tend.  Normally  the  binding  between  an  identifier  and 
an  object  is  'forgotten'  at  the  end  of  the  transaction.  However,  export  can  be  used  to 
preserve  the  binding  for  subsequent  transactions.  For  exeimple,  the  following  transac¬ 
tion  creates  an  instance  of  Employee,  initializes  various  properties,  eind  exports  the 
new  object. 

tbegin 

create  an  EJmployee  \sjohn-, 
ixssert  John. Name  is  "John  Smith"; 

EiSsertjohn.ScUl  is  newskill; 
assert  newskill.  Job  Category  is  "electrician"; 
assert  newskill.  Years  Experience  is  2; 
export 

tend 


Query  operations  are  used  to  bind  identifiers  to  sets  of  objects  present  in  the 
data  space.  There  are  two  methods  for  query  specification:  selection  and  extension. 
Some  examples  of  selection  using  the  Employee  and  Department  object  types  are 

1)  employees  who  earn  more  than  their  manager 

set  overpaid  is  Employee  where  Salary  >  ManagedBy. Salary, 

2)  electricians  with  four  years  experience 

set  elec4  is  Employee  where 

(some  SfciiZ  has  Job  Category  =  "electrician"  and  Years  Experience  =  4); 

A  query  based  upon  extension  binds  the  v^alue  of  a  multivalued  property  or  constituent 
to  an  identifier.  Some  examples  are 

1)  the  job  categories  otjohn 

sgX.  jobsofjohn  is  john.Scill.  Job  Cate  gory, 

2)  the  job  categories  of  the  manager  oljohn 

set  jobsofboss  is  john:  Manage  dBy.  Skill.  Job  Cat  eg  ory. 
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A  for  operation  provides  set  iteration  and  single  object  queries  are  performed  by  re¬ 
placing  the  ke3^ord  set  by  object. 

3  Domains.  Triggers  and  Templates 

In  this  section  we  introduce  three  constructs,  domains,  triggers,  and  template 
types,  that  are  used  in  modelling  office  objects.  Domains  are  defined  data  types  that 
describe  the  formats  of  property  values.  During  data  entry  there  are  two  contending 
forces;  if  processing  is  to  occur  at  some  later  stage,  restrictions  are  imposed  on  the 
format  of  entered  values;  the  user,  however,  views  data  formats  as  arbitrary  and  un¬ 
necessary  complications.  To  provide  greater  flexibility,  we  allow  domains  to  have 
meiny  formats  (or  external  representations)  and  translate  to  a  single  internal 
representation  for  processing  and  storage. 

A  large  variety  of  constraints  appear  when  modelling  the  office.  For  this  reason 
we  have  chosen  to  express  only  a  small  number  of  constraints  declaratively  (those 
within  the  object  type  definition)  and  to  use  triggers  [5,  36]  for  the  remainder.  A 
trigger  is  essentially  a  pattern-invoked  procedure  and  can  be  used  to  test  pre  and 
postconditions. 

A  template  type  [33]  is  a  specification  of  how  an  object  or  set  of  objects  is  to  be 
presented  in  a  particular  medium.  Generic  examples  include  icons  [14,  30],  form- 
blanks,  and  tables.  Here  we  consider  templates  for  three  media  --  character  oriented 
devices,  graphic  devices,  and  audio  devices. 


-  7  - 


3.1  Domain  Dennition 


A  domain  definition  encapsulates  the  functions  used  to  recognize  domain  ele¬ 
ments,  transform  between  internal  and  external  representations,  and  perform  opera¬ 
tions  upon  domain  elements.  "We  treat  domains  as  abstract  data  types  defined  in  the 
underlying  implementation  language. 

Each  domain  is  equipped  with  the  following  standard  set  of  functions  (a  Pascal- 
like  syntax  is  used  for  illustration) 

Ini  ti  al  i  z  e  Ito  mainName ; 

Parsei>>mainAfctme(V:  external-rep):  internal-rep; 

y alidd^tv Domain Nam.e{v.  internal-rep):  boolean-, 

Fbrmat  WameYormaiirhmainName{v-.  internal-rep); 

The  initialization  function  simply  initializes  any  variables  or  data  structures  used 
within  the  domain  definition.  The  parsing  and  validation  functions  are  automatically 
called  when  a  value  in  an  external  representation  is  encountered.  These  functions 
generate  the  value's  internal  representation  and  verify  its  correctness.  The  format 
functions  are  used  to  output  domain  elements  in  the  external  representation 
identified  by  f  irmat Name . 

As  an  example,  suppose  we  define  the  domain  Date  for  properties  with  dates  as 
values.  The  internal  representation  of  Date  could  be  three  integers  for  the  day. 
month,  and  year,  while  the  external  representation  would  be  a  string.  The  function 
ParseDate  can  be  defined  to  recognize  the  two  formats:  "month  dd,  yyyy"  and 
"mm/dd/yy";  the  ValidateZ^ife  function  would  then  determine  such  things  as  whether 
the  day  and  month  are  in  valid  ranges.  Conversion  to  an  external  representation  can 
be  achieved  using  Defa^dtFormatDate  to  output  domain  elements  as  "mm/dd/yy"  or 
TraditionalFormalDate  to  produce  "month  dd,  yyyy".  Other  formatting  functions 
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could  be  added  as  desired.  For  example,  FYenchYormdXDate  prints  month  names  in 
French  rather  than  English. 

A  domain  may  contain  additional  functions  for  processing  domain  elements. 
Three  useful  functions  for  Date  are 

on(dl,  d2:  Aite-internal-rep):  boolean-, 
before(dl,  d2:  iMe-internal-rep):  boolean-, 
next(d:  Aif e-internal-rep):  itot^e-internal-rep; 

The  first  two  functions  return  a  boolean  value  and  so  are  easily  incorporated  within 
the  selection  condition  of  a  query.  The  third  returns  a  Date  domain  element  and 
would  be  used  with  the  assert  operation. 

3.2  Unformatted  Data  Types 

The  data  type  of  a  property  is  either  a  domain,  as  defined  above,  or  one  of  the 
primitive  data  types.  The  standard  primitive  data  types  include  booiean,  char,  integer, 
real,  and  string{n)-,  to  represent  office  objects  we  need  to  add  audio,  image,  text,  and 
digital  to  the  list.  The  audio  and  image  types  are  used  for  digitized  voice  and  image, 
the  text  type  is  used  for  variable  length  character  strings.  The  digital  type  is  a  com¬ 
mon  representation  for  the  previous  three  and  is  used  with  objects  that  handle  unin¬ 
terpreted  digital  data. 

The  problems  associated  with  the  storage  of  unformatted  data  values  or  with 
low-level  processing  do  not  concern  us  here.  Instead  we  are  interested  in  the  opera¬ 
tions  a  user  is  likely  to  require  in  performing  office  work.  Table  1  lists  the  operations 
assumed  to  be  provided  by  the  implementation  language  for  the  unformatted  data 
types. 
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_ Table  1  Processiug  functions. _ 

InpulAudio;at«iio:  In  pu  LI  mage:  image;  InputText:teart; 

E]ditAudio(a:at«iio);ai4<iio;  Editlmage(i;imagre):image;  EditText(t:iext):tea;t; 

OulputAudio(a:at«iro);  ♦  ♦ 

MatchAudio(v,p:ati<iio):6ooiean;  MatchImage(v,p;image);6oo£ean;  MatchText(v,p:text):i>ooIean; 
SpeechRecog(a:au(iio);text;  ♦  SpeechSynth(t:texi):at4<iio; 

•  CharRecog(i;image):iezt;  TypeSet(t:tea:i);image; 

PackAudio(a:audio):ci‘igiia/;  UnPackAudio(d:d'igiiaZ):at4dio;  * 

Packlmage(i;tmage):digi<ai;  UnPackImage(d;disritai);image;  • 

PackText(t:text):dtgiiaZ; UnPackText(d:dTflriia^):texi; * 

The  invocation  of  either  an  Input  or  an  Edit  function  gives  control  to  an  editor, 
allowing  the  user  to  create  or  modify  a  value  of  the  associated  data  type.  OutputAudio 
passes  control  to  a,  possibly  interactive,  program  that  outputs  a  single  audio  value 
(output  of  text  and  image  values  is  controlled  by  templates). 

A  Match  function  determines  whether  the  pattern  p  is  contained  within  the 
value  v.  The  language  AWK  [2]  contains  many  of  the  pattern  matching  capabilities 
useful  for  text  processing.  For  audio  and  image  values,  we  are  aware  that  pattern 
matching  is  not  currently  possible  in  general:  our  aim  here,  though,  is  to  show  how 
these  cap>abilities  could  be  incorporated  if  present. 

Conversions  between  audio  and  text  values  are  represented  by  the  functions 
SpeechSynth  and  SpeechRecog.  Currently  continuous  speech-recognition  is  only  pos¬ 
sible  under  stringent  conditions  such  as  a  small  vocabulary  and  a  single  speaker  [24]. 
The  inverse  function,  speech  synthesis  from  text,  is  readily  available  [35]  and  has 
been  used  in  proto- type  office  systems  [19].  Conversions  between  text  and  image  data 
also  occur  in  office  information  systems,  these  are  expressed  by  the  Type  Set  and  Char- 
Recog  functions.  The  first  function  takes  a  text  value,  possibly  containing  font  and 
point  size  information,  and  produces  a  typeset  image  of  the  text.  The  second  function 
corresponds  to  OCR  (Optical  Character  Recognition)  and  extracts  a  text  string  from  an 

image  value. 
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The  six  functions  associated  with  digital  are  used  for  conversions  to  and  from 
audio,  image,  and  text.  These  functions  are  not  excessively  complicated.  For  exam¬ 
ple,  if  an  image  value  is  represented  by  an  array,  then  Packimage  concatenates  the 
rows  of  the  array  and  attaches  a  header  indicating  the  original  t3rpe  and  the  array  di¬ 
mensions,  while  UnPackImage  reconstructs  the  image  value. 

As  an  example  of  the  use  of  these  functions,  suppose  we  have  the  object  type 


define  object  type  Student  begin 
j»‘operties; 

Student  -»  Name,  Ffioto', 

Photo  ^  Feature +  ,  Picture-, 

constraints: 

data  type  of  Name  is  Name  Vai\ 
data  t}^  of  Feature  is  Feature  Val-, 
data  type  of  Picture  is  image-, 

end 


then  possible  operations  are 


set  si  is  Student  where  "brown  hair"  e  Photo. Feature-, 

set  is  Student  where  SpeechRe  cog  (Input  Audio)  e  Photo.  Feature-, 

assert  mary. Photo. Picture  is  Inputlmage; 


3.3  Trigger  Definition 


A  trigger  definition  has  the  following  general  form. 


define  trigger  WggerNam.e  begin 
pattern: 

activation  pattern,  type  restrictions 
condition; 

a  condition 

error; 

an  error  message 

action; 

a  list  of  operations 

end 
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The  pattern  section  identifies  the  operation  which  activates  the  trigger  and  may  give 
restrictions  on  the  types  of  objects  appearing  in  the  operation.  Triggers  can  be  ac¬ 
tivated  by  the  following  operations:  create,  destroy,  assert,  remove,  and  tend  The  ac¬ 
tivation  pattern  is  written  at  the  beginning  of  the  pattern  section  and  resembles  an 
object  operation  (with  the  exception  of  triggers  on  tend  these  will  be  discussed 
separately).  Identifiers  preceded  by  a  question  mark  may  appear  within  the  pattern. 
These  are  bound  upon  activation  and  can  be  referred  to  in  succeeding  sections  of  the 
trigger.  This  method  for  specifying  activation  patterns  derives  from  PLANNER  [15]. 

In  many  cases  it  is  only  necessary  to  activate  the  trigger  if  the  objects  appear¬ 
ing  within  the  activation  pattern  are  of  some  specific  type.  For  each  such  object  one 
can  add  a  restriction  of  the  following  kind. 

object  type  of  ObjectName  is  [not]  ObjectTypeName] 

As  an  example  of  trigger  activation  consider  the  following. 

pattern: 

assert  ?t:SubPaTt  is  ?x; 
object  type  of  f  is  7Vay; 
object  type  of  x  is  not  Envelope] 

This  pattern  will  cause  the  trigger  to  be  activated  only  when  objects  which  are  not  of 
type  Envelope  are  made  the  SubPart  of  a  Tray. 

As  mentioned  above,  the  activation  patterns  for  triggers  on  tend  are  unusual. 
These  patterns  are  written  as 

pattern: 

operation:  tend 

If  the  operation  within  the  pattern  appears  in  a  transaction,  the  trigger  is  activated 
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upon  reaching  the  tend  and  can  then  test  postconditions.  If  the  transaction  fails,  ei¬ 
ther  from  an  abort  or  integrity  violations,  the  trigger  is  not  activated. 

The  condition  section  contains  a  single  condition  with  a  syntax  similar  to  that 
used  in  the  query  operations.  An  example  is 

pattern; 

assert  '^e.  Salary  is  7^:; 

condition; 

(x  >  e. Salary)  or  {e. Salary  =  NULL); 

The  condition  of  an  activated  trigger  must  be  satisfied  before  the  operation  activating 
the  trigger  can  be  performed. 

The  error  section  contains  a  string  which  is  displayed  when  the  trigger’s  condi¬ 
tion  fails.  An  error  section  appropriate  for  the  above  example  would  be 

error; 

"salaries  cannot  be  decreased": 

The  final  section  contains  a  list  of  operations.  Any  of  the  object  operations  ex¬ 
cept  tbegin  and  tend  may  be  used.  (These  two  operations  are  excluded  so  as  to  prevent 
the  nesting  of  transactions.) 

Using  triggers  we  can  express  many  of  the  constraints  that  occur  within  ob¬ 
jects  (constraints  on  single  properties  are  best  left  to  domain  definitions).  For  exam¬ 
ple,  we  will  look  at  some  of  the  constraints  that  appear  in  forms  [8]. 

define  trigger  variant-field  begin 
pattern;  assert  7f.Pis  ?v, 
condition  f  .Q=  x’; 
error;  "Q  not  selected"; 

end 

define  trigger  virtual-field  begin 
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pattern  assert  ?/.Pis  ?t;: 
action:  assert  f.R  is  {f.P  +  f.Q)-, 

end 

Triggers  such  as  variant-fieLd  are  used  when  a  property  (or  group  of  properties)  can¬ 
not  be  given  values  unless  another  property  has  been  'selected'.  In  this  exeimple  P 
can  only  be  given  a  value  when  Q  has  the  value  'x'.  The  virtual-field  trigger  illustrates 
how  a  property  may  be  derived  from  other  properties.  In  this  case  the  property  Ris 
the  sum  of  P  and  Q.  This  trigger  is  activated  when  P  is  given  a  value,  we  would  edso 
need  a  trigger  on  Q.  In  a  similar  fashion,  triggers  can  be  used  to  construct  a  variety  of 
form  fields:  these  include  required  fields,  fields  with  default  values,  personalized 
fields,  and  unmodifiable  fields, 

3.4  Tem^ate  Types 

A  template  type  is  analogous  to  an  object  type;  it  specifies  the  structure  of  in¬ 
stances,  which  in  this  case  are  particular  templates.  There  are  three  generic 
categories  of  templates,  audio  templates,  image  templates,  and  text  templates.  In  the 
following  we  describe  how  these  may  be  specified  and  the  operations  involving  tem¬ 
plates. 

3.4.1  Audio  Templates 

The  syntax  of  an  audio  template  type  definition  is 

define  audio  template  type  Template  Type  Name  for  an  Object  Type  Name  begin 
background 

utterance  specifications 

slots; 

slot  specifications 

end 

The  definition  identifies  the  name  of  the  template  type  and  the  object  type  with  which 


-  14- 


It  is  used.  The  background  section  is  a  list  of  audio  values  (utterances)  interspersed 
with  slot  markers.  There  is  a  problem  in  depicting  both  slots  and  utterances  on  paper. 
Here  we  let  a  string  enclosed  by  exclamation  marks  represent  an  utterance.  (Howev¬ 
er,  we  should  keep  in  mind  that  the  utterance  is  actually  an  audio  value.)  Slot  mark¬ 
ers  are  represented  by  angled  brackets  enclosing  the  slot  name. 


The  slots  section  contains  a  list  of  slot  definitions  of  the  form 


sLotname;  name  of  the  slot 

contents;  description  of  contents 


The  value  of  the  contents  attribute  is  either  a  property  name  from  the  object  type  as¬ 
sociated  with  the  template  or  an  implementation  language  function. 


A  simple  example  of  an  audio  template  is 


define  audio  template  type  Announce  Mail  for  an  Envelope  begin 
utterance; 

<sl>  !your  mail  from!  <s2>  lhas  arrived! 

slots; 

slotname;  si 

contents;  Greetings 
slotname;  s2 

contents;  E’om 

end 


The  Greetings  function  returns  an  utterance  such  as  !Good  morning!  or  !Good  after¬ 
noon!.  FYom  is  one  of  the  properties  of  Ejnvelope. 

3.4.2  Image  and  Text  Templates 


The  syntax  of  a  image  template  type  definition  is 

define  image  tenq^ate  type  Template  Type  Name  for  [an]  Object  Type  Name  begin 
background 

image  specification 

boxes; 
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end 


box  specificaUons 


The  keyiivord  an  indicates  that  TemplateTi/peName  is  used  to  display  single  instances 
of  Objec  t  Type  Name ,  otherwise  a  set  of  instainces  may  be  displayed. 

The  background  section  specifies  an  image  data  value  that  consists  of  a  number 
of  rectangular  boxes.  (Here  boxes  are  simply  display  structures,  similar  to  those 
found  in  TKX  [17]  and  should  not  be  confused  with  the  boxes  of  SBA  [5].)  A  box  has  a 
name  and  may  contain  additional  boxes  or  arbitrary  image  data.  Additionally,  each 
box  may  have  an  upper  and  lower  margin. 


The  boxes  section  of  a  template  definition  gives  attribute  values  for  each  box 
appearing  in  the  background  section.  Table  2  lists  various  box  attributes.  In  many 
cases  default  values  can  be  used  and  the  attribute  need  not  appear  in  the  box 
specification.  Additionally,  certain  attributes,  such  as  font  type  and  line  spacing,  give 
only  initial  values  and  may  be  overridden  within  the  box. 


expandable 
repeating 
contents 
ordering 
line  spacing 
font  type 
font  size 
borders 
iustillcation 


_ Table  2  Box  attributes. _ 

used  for  variable  length  data 

used  with  multivalued  properties 

identifies  the  value  appearing  in  the  box 

determines  the  order  in  which  values  are  displayed 

line  spacing  used  in  the  box 

font  used 

font  size  used 

determines  if  box  borders  are  displayed 
indicates  if  the  value  is  centered,  left  justified,  etc. 


A  small  number  of  predefined  boxes  and  templates,  the  PageBox,  AudioBox,  Set- 
TbmpLate,  and  Table  Template,  can  be  used  with  template  definitions.  These  four  con¬ 
tain  control  symbols,  similar  to  the  graphic  symbols  found  in  Bravo  [18]  or  Star  [30], 
that  are  used  to  initiate  operations.  The  first,  PageBox,  is  for  templates,  usually  of  do¬ 
cuments,  that  are  too  long  to  be  displayed  with  a  single  screen.  Boxes  internal  to  a 
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PcLgeBox  determine  the  formatting  of  the  document  (as  with  the  pcige  templates  of 
JANUS  [3]).  Successive  pages  ai'e  displayed  by  selecting  the  various  controls.  The  Au- 
dioBox  is  used  when  audio  valued  properties  must  be  accessed  from  an  image  template 
(eg.  voice  annotation).  Depending  upon  the  context,  the  user  may  use  an  Audio  Box  to 
initiate  either  the  Input  Audio.  EditAudio,  or  Output  Audio  function.  The  Set  Template  is 
used  to  flip  through  a  set  of  objects.  The  controls  are  similar  to  those  of  PageBox.  The 
Thble Template  is  used  for  displaying  sets  of  objects  in  tabular  form.  Here  the  controls 
are  for  adding  or  dropping  columns  and  for  inserting  or  deleting  rows. 

Text  templates  differ  from  image  templates  only  in  minor  details.  The  back¬ 
ground  is  now  a  text  value  as  opposed  to  an  image  value,  also  some  box  attributes, 
such  as  those  related  to  fonts,  are  no  longer  applicable.  Other  than  this,  the  discus¬ 
sion  on  image  templates  applies,  in  its  main  points,  to  text  templates. 

3.4.3  Tem^^te  Operations 

There  are  four  template  operations:  template,  embed,  present,  and  erase. 
These  can  be  thought  of  as  generalized  output  operations  and  may  appear  at  any  point 
within  a  transaction. 

The  template  operation  declares  an  identifier  which  is  used  to  refer  to  a  specific 
template.  If  it  is  necessary  to  use  this  identifier  in  more  than  one  transaction  it  must 
be  exported.  A  template  behaves  as  a  data  value.  For  example,  if  we  have  defined  an 
image  template  type  named  Let  ter  Template  and  perform  the  template  operation 

template  t  is  Let  ter  Template-, 

then  t  can  be  assigned  as  a  value  to  properties  based  on  the  image  data  type. 
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The  embed  operation  combines  an  object,  or  set  of  objects,  with  a  template. 
The  operation  converts  property  values  to  the  data  t3i^e  of  the  template  by  applying 
functions  such  as  TypeSet  or  SpeechSynth.  (The  template  designer  should  be  aware  of 
the  limitations  of  these  functions  when  specifying  the  properties  that  appear  in  a  tem¬ 
plate.)  The  embed  operation  produces  a  single  data  value,  bound  to  the  template 
identifier,  which  represents  the  merging  of  object  and  template. 

The  physical  realization  of  a  template,  possibly  containing  embedded  objects,  is 
achieved  using  the  present  operation.  For  audio  templates,  present  simply  outputs 
the  value  of  the  template.  Text  and  image  templates  are  displayed  on  the  screen  at  a 
specified  location.  A  particular-  template  may  only  appear  at  one  location  on  the 
screen,  however,  templates  may  overlap.  The  erase  operation  removes  a  template 
from  the  screen,  allowing  it  to  be  presented  at  a  second  location.  Audio  templates,  be¬ 
cause  of  their  transient  nature,  can  be  repeatedly  presented. 

We  now  look  at  a  complete  example  using  the  template  operations.  Assume  the 
object  type  Letter  has  a  text-valued  property  named  Body  and  a  property  named  Wri- 
teDate  based  on  the  Date  domain.  Consider  a  transaction  that  retrieves  an  instance  of 
[£tter  and  displays  this  object  in  Letter  Template  at  the  upper  left  corner  of  the 
screen. 

tbegin 

template  t  Is  Letter  Template-, 
object  I  is  Letter  where 

MatchText(ii’od'y,  "office  system")  and  on{  Write  Date ,  "May  23,  1983"); 
embed  I  in  t, 
present  t  at  (0,0); 

tend 
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Successful  termination  of  a  transaction  causes  all  image  and  text  templates  lo¬ 
cal  to  the  transaction  to  be  erased.  If  the  transaction  fails  or  is  aborted  then  the 
screen  is  restored  to  its  original  state  (this  requires  erasing  any  templates  drawn  by 
the  transaction  and  redrawing  any  previously  exported  templates  that  have  been 
erased).  In  the  above  example,  unless  the  template  t  is  exported  it  will  be  erased 
when  the  tend  is  reached 


4  Application  to  the  Office  Environment 

In  this  section  we  describe  some  useful  objects  and  illustrate  how  commands 
available  to  the  user  are  expressed  in  terms  of  object  operations.  We  concentrate  on 
representing  ’office  objects',  these  are  the  computer-based  versions  of  such  things  as 
forms  and  documents. 


4.1  Representation  of  (MBice  Objects 


The  most  general  class  of  office  objects  is  specified  by  the  type  Office  Object 
which  has  two  specializations.  Simple  and  Aggregate.  These  are  defined  as 


define  object  type  Office  Object, 

define  object  type  Aggregate  begin 
constituents; 

Aggregate  ^  SubPca^t+-, 
mappings; 

Sab  Part  :  Part  Of  ->  Aggregate-, 

Sab  Part  :  Co  Part  ^  Sab  Part, 
constraints; 

object  type  of  SabPart  is  Office  Object, 

[S^bPart]  is  unique; 

end 

define  object  type  Smple-, 


Aggreg ate  is-a  Cffic e Object, 
Simple  is-a  Office  Object, 
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Simple  form  a  partition  of  OfficeObject.  The  difference  between  Aggre¬ 
gate  and  Simple  is  the  SibPart  constituent.  SubPart  and  its  inverse,  PartOf,  are  used 
to  model  the  containment  relationship  between  office  objects  [9].  The  constreiint  sec¬ 
tion  of  Aggregate  indicates  that  this  constituent  is  unique.  This  constrains  an  in¬ 
stance  of  OfficeObject  to  be  the  SubPart  at  most  one  aggregate  object.  If  vre  view  the 
object  which  contains  a  second  object  as  the  'location'  of  the  second  object  then  this 
constraint  tells  us  that  office  objects  can  only  be  in  one  place  at  one  time.  Thus  we 
have  captured  cin  important  aspect  of  physical  objects  by  imposing  uniqueness  on  the 
SubPart  constituent. 

One  feature  of  office  objects  not  expressed  in  the  above  definitions  is  that  con¬ 
tainment  is  type  sensitive.  For  example,  in  the  real  office  a  mail  tray  cannot  contain 
a  desk,  a  dossier  cannot  contain  a  mail  tray,  and  so  on.  There  are  a  number  of  ways  to 
model  this  constraint.  One  method  is  to  assign  a  volume  to  each  office  object.  The 
definition  for  Office  Object  would  then  become 

define  object  type  Office  Object  begin 
fMToperties: 

.  OfficeCbject  -*  Volume] 

constraints: 

rlata  type  of  Volume  is  integer] 

end 

By  using  the  trigger 

define  trigger  ChechSpace  begin 

pattern;  assert  lx:3ubPart  is  ?y; 

condiUon:  y.  Volume  <  x.  Volume  -  sum(r;5h6Rirf.  Volume)] 
error;  "there  is  no  room  left"; 

end 

we  can  prevent  physically  impossible  containment  relationships  from  being  esta¬ 
blished.  This  method  has  a  number  of  disadvantages  though.  First  there  is  a  problem 
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in  assigning  values  to  VoluTne,  any  system  we  choose  will  be  arbitrary.  Secondly,  all 
objects  of  a  particular  type  will,  in  many  cases,  have  the  same  volume;  it  is  not  needed 
to  specify  this  value  for  each  instance.  Finally,  we  do  not  really  wish  to  impose 
deficiencies  of  physical  objects  upon  the  C^ice Object  type;  having  an  essentially 
infinite  volume  can  be  useful.  Instead  we  merely  wish  to  forbid  containment  relation¬ 
ships  which  are  incompatible  with  the  office  worker’s  conception  of  office  objects. 

A  second  approach,  and  that  adopted  here,  is  based  upon  the  two  object  types 
Moveable  and  Stationary  which  are  defined  as 

define  object  type  Moveable: 

define  object  type  Stationary: 

Moveable  is-a  OffioeObject: 

Stationary  OfficeObject: 

As  with  Simple  and  /^gregale,  these  two  t3^es  partition  Office  Object.  Moveable  and 
Statixmary  differ  with  respect  to  Part  Of .  Instances  of  Moveable  may  be  Part  Of  any  ag¬ 
gregate,  instances  of  Stationary,  on  the  other  hand,  may  only  be  PartOf  one  specific 
type  (known  as  Station).  While  the  distinction  between  Moveable  and  Stationary  is 
rather  coarse,  it  is  sufficient  to  prevent  many  absurd  containment  relationships  from 
occurring. 

Every  office  object  is  an  instance  of  either  Simple  or  Aggregate  and  either  Move- 
able  or  ^:atwnary.  Thus  there  are  four  possibilities,  some  examples  of  each  are 

Sample /Moveable  forms,  letters,  documents. 

Simple/ St atioTvary  printers,  telephones,  clocks. 

Aggregate  /Moveable  envelopes,  dossiers,  files. 

Aggregate  /Stationary  desks,  trays,  cabinets. 

Aggregate  objects  induce  a  hierarchy  of  containment  relationships  upon  instances  of 
OfficeCbject.  Grouping  together  of  objects  within  a  single  aggregate  is  a  basic  method 
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for  organizing  information  in  the  ofTicc.  'ITie  following  are  common  specializations  of 
Aggregate. 


•Station  Instances  of  the  Station  object  type  correspond  to  the  workstations  of 
an  office  information  system.  A  station  is  an  object  which  groups  together  all  objects 
used  by  a  single  user,  or  in  common  by  a  group  of  users.  The  physical  counterpart  of 
a  station  would  be  an  office  (i.e.  a  room)  or  perhaps  a  section  (i.e.  an  area  occupied  by 
a  number  of  people  performing  the  same  tasks). 

Two  constraints  involve  the  Station  object  type.  First,  a  station  is  the  ’largest’ 
aggregate  object,  that  is,  stations  cannot  PartOf  any  other  object.  This  constraint  is 
enforced  by  the  following  trigger. 


define  trigger  StatixtnSuJb Part  begin 

pattern:  assert  ?x:SnbRirt  is  ly, 
object  type  of  y  is  Station: 
condition;  false; 

error;  ’’stations  cannot  be  SubParts”; 

end 


Secondly,  objects  of  type  Stationjary  ceui  only  be  PartOf  stations. 


define  trigger  Stationary  Sub  l^rt  begin 
pattern:  assert  ?x:SubPart  is  ?y; 

object  type  of  x  is  not  Station: 
object  type  of  y  is  Stationary: 
condition;  false; 

error;  ’’stationary  objects  can  only  be  SubParts  of  stations"; 

end 


’The  properties  of  Station  are  related  to  the  addressing  logic  used  by  the  office 
information  system  [21].  For  example,  suppose  the  definition  of  Station  contains  a 
property  named  Role  where  values  of  Role  (particular  roles)  are  the  titles  or  positions 
of  office  personnel.  This  gives  rise  to  an  addressing  scheme  in  which  it  is  not  neces- 
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sary  to  know  the  names  of  people  playing  roles.  If  Role  is  a  unique  property,  we  can  be 
sure  that  a  role  will  identify  a  single  station  and  addressing  by  role  is  unambiguous. 

•Envelope  The  Envelope  object  type  is  used  to  group  together  objects  which  are 
being  sent  from  one  station  to  another.  Two  properties.  From  and  7b.  are  used  to  iden¬ 
tify  the  source  and  destination  stations. 

•Dossi,er  A  dossier  is  simply  a  named  collection  of  objects.  The  Dossier  object 
type  has  a  single  property,  DossierName,  for  naming  dossier  instances. 

•Desk  The  Desk  object  type  is  used  to  provide  working  areas  for  the  users  of  a 
station.  Since  it  is  possible  that  stations  will  contain  more  than  one  desk,  a  property 
such  as  DeskName  is  necessary  to  distinguish  between  instances, 

•Cabinet  Cabinets  are  used  to  group  together  objects,  but  differ  from  dossiers  in 
that  they  are  stationary  and  all  objects  contained  within  a  particular  cabinet  must  be 
of  the  same  type.  The  various  specializations  of  the  object  type  Cabinet  give  rise  to 
cabinets  for  specific  object  types,  an  example  would  be  OrderCabinet  for  the  type  Or- 
derfbrm. 

•Tray  Mail  trays  provide  a  mechanism  for  transferring  objects  from  one  station 
to  another.  The  object  type  Tray  has  two  specializations,  InTray  and  OutTray.  Each 
station  contains  both  a  single  fnTray  instance  and  a  single  ChitTray  instance. 

Previously  we  have  used  triggers  solely  to  specify  constraints  on  the  properties 
or  constituents  of  an  object.  Triggers  can  also  be  used  to  specify  procedures  [5,  16, 
38].  Consider  the  object  transfer,  or  mailing,  operation.  When  an  envelope  is  put  in 
an  out  tray  we  need  to  transfer  the  envelope  to  the  in  tray  of  the  destination  station, 
Triggers  are  well  suited  for  such  event  driven  procedures;  the  pattern  section  of  the 
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trigger  corresponds  to  the  event  activating  the  procedure,  the  action  section 
corresponds  to  the  body  of  the  procedure.  'Ihe  MaiLFJnvelope  trigger  is  defined  as 


define  trigger  ^failKnvelope  begin 

pattern;  assert  ^ojSubPart  is  ?e; 

object  type  of  o  is  Out  Tray, 
object  type  of  e  is  En.velope', 
condition:  (some  Station  has  e.Tb  =  Role)', 
error;  "bad  destination"; 
action:  object  i  is  fnTray  where 
e.Tb  =  Part  Of  Role-, 
remove  o:  Sab  Part  is  e; 
assert  i:3abPart  is  e; 

end 


Different  addressing  schemes,  such  as  addressing  by  user  name  or  a  combination  of 
name  and  role  can  be  sp)ecified  by  redefining  Station,  Envelope,  and  MailBhivelope. 

A  more  complicated  addressing  scheme  occurs  when  the  destination  station  is 
identified  by  a  selection  condition.  In  this  case,  the  following  object  type  is  used  to 
represent  the  association  between  a  user  and  the  station  operated  by  the  user. 


define  object  type  l^es  begin 
constituents: 

Uses  >  i^er.  Terminal', 

noappings: 

User.Operates  -*  Terminal', 
'IkTmin.al:  Operated  By  User, 

constraunts: 

object  type  of  User  is  Employee, 
object  type  of  Terminal  is  Station', 
( User)  is  unique, 

end 


We  assume  that  a  user  may  only  operate  a  single  station,  hence  the  constituent  User 
is  unique.  As  an  example  of  addressing  by  selection  condition,  consider  the  problem  of 
locating  the  stations  whose  operators  earn  more  than  a  certain  amount. 


set  destlist  is  Station  where 

Operate  dBy. Salary  >  20000; 
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The  set  of  stations,  destList,  that  is  found  by  this  query  can  be  used  as  a  mailing  list  to 
distribute  a  particular  object.  For  example, 


for  d  in  destList  do 

object  i  is  fn'Pray  where 
Part  Of  ~  d; 
object  y  is  copy  of  r; 
assert  i:SubPart  is  y, 

end 


puts  a  copy  of  x  into  the  in  tray  of  each  station  in  destList. 

A  final  addressing  scheme  that  is  common  in  the  office  is  the  automatic  routing 
of  objects  based  upon  property  values.  In  order  to  include  such  addressing  we  intro¬ 
duce  the  object  type  Routed,  instances  of  which  are  automatically  routed.  Routed  is  a 
specialization  of  Offine Object,  specializations  of  Routed  are  the  types  which  are  au¬ 
tomatically  routed.  We  have  seen  that  the  routing  of  Envelope  is  automatically  deter¬ 
mined  by  the  7b  property.  Enuelope  is  then  a  specialization  of  Routed,  i.e.. 


Envelope  is-a  Aggregate, 

Envelope  is-a  Routed, 

Simple  objects  may  also  be  automatically  routed.  For  example,  if  the  object  type  Or- 
derForm  has  automatic  routing  then  we  will  have 

Order Fbrm  is-a  Simple-, 

Order Fhrm  is-a  Routed-, 


The  constituents  of  trays  must  be  routed  objects,  the  following  trigger  expresses  this 
constraint. 


define  trigger  Route  dOnly  begin 

pattern:  assert  ?t:Sub  Part  is  ?x: 
object  tyjxj  erf  /!  is  7hay; 
object  type  of  x  is  not  Routed-, 
condition;  false; 
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error;  "rouLcd  objects  only  in  trays"; 

end 

For  each  specialization  of  J^uted,  a  trigger  is  defined  for  performing  the  routing 
operation.  The  MaiLEHyelope  trigger  defined  previously  is  the  routing  trigger  for  the 
Envelope  object  type,  lor  the  OrderFbrm  object  type  let  us  assume  that  all  instances 
are  routed  to  the  role  "shipping  clerk".  The  routing  trigger  is  then 

define  trigger  Order Phrm  begin 

pattern  assert  ?o:SubPart  is  ?/; 

object  type  of  o  is  Oat  Tray, 
object  type  of  /  is  OrderFbrm-, 
action;  object  i  is  InTray  where 

Part  Of  .Role  =  "shipping  clerk"; 
remove  Q:SabPart  is  /; 
assert  i:SubPart  is  /; 

end 

Here  the  modularity  of  routing  triggers  is  apparent.  The  two  triggers  MaiiEnvelope 
and  Mail  Order Thrm  are  completely  independent.  To  introduce  a  new  object  type  re¬ 
quiring  routing,  provided  the  new  type  is  a  specialization  of  Routed,  it  is  only  neces¬ 
sary  to  define  the  appropriate  routing  trigger. 

The  office  objects  we  have  described  above,  although  originating  from  real- 
world  entities,  exist  solely  within  the  model.  It  is  also  useful  to  have  office  objects 
that  refer  to  physically  existing  entities  such  as  hardware  devices.  Here  we  assume 
that  the  system  implementing  the  model  automatically  alters  the  properties  of  these 
objects  when  their  external  state  changes.  VlTe  will  consider  one  example,  the  (digital) 
telephone.  Consider  a  Telephone  object  type  with  properties 

Telephone  ->  Send,  Rec,  MyNwm,  DixilNum,  MyState-, 

Send  and  Rec  use  the  digital  type  and  are  for  sending  and  receiving  data.  The  proper¬ 
ties  MyNam  and  DialNam  correspond  to  the  number  of  the  phone  and  the  number  be- 
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ing  dialed.  MyState  indicates  the  state  of  the  telephone  and  has  values  such  as  "ring¬ 
ing”,  "connected",  "dialtone",  "ringtone",  etc. 

Using  triggers  and  templates  one  can  represent  such  activities  as  automatic 
answering  and  facsimile  transmission.  Suppose  the  identifier  myphone  is  bound  to  a 
ThlephoTie  instance.  Then  the  trigger 

define  trigger  Answer  Phone  begin 

pattern;  assert  myphone.  My  St  ate  is  "ringing": 


is  activated  when  the  state  of  myphone  changes  to  "ringing".  The  action  section  of  the 
trigger  specifies  the  appropriate  operations.  For  facsimile  transmission,  assume  that 
a  connection  has  been  established.  Now  suppose  the  user  wants  to  send  the  image  of 
object /in  template  t.  The  necessary  operations  are 

embed  /  in  f; 

assert  myphone. Send  is  Packlmage(f): 

The  receiver  can  then  use  UnPackImage  to  reconstruct  the  image. 

Data  within  the  office  has  been,  classified  as  internally  or  externally  developed 
[12].  The  facsimile  example  illustrates  the  difference  between  what  can  be  called 
internal  and  external  communication.  For  internal  communication,  when  the  sender 
and  receiver  share  the  same  data  space,  we  transfer  an  object  by  manipulating  the 
PartOf  hierarchy.  For  external  communication,  as  with  an  outside  organization,  we 
embed  the  object  in  a  template  and  send  the  relatively  unstructured  template  value. 
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4.2  User  Commands 


In  the  preceding  we  have  described  the  operations  for  creating,  retrieving,  and 
modifying  objects.  However  these  operations  are  not  suitable  for  casual  user  interac¬ 
tion;  they  are  at  too  low  a  level  of  detail  and  the  syntax  is  too  cumbersome.  In  this 
section  we  illustrate  how  user'-level  commands  are  translated  to  object  operations. 

First  we  consider  the  query  command  as  used  in  OFS  [32],  a  form  system  based 
on  a  relational  database.  In  OFS,  queries  are  specified  by  entering  selection  condi¬ 
tions  on  a  form  template  (this  method  is  similar  to  Query-by-Example  [37]).  The  user 
then  specifies  a  scope  [23]  which  indicates  the  stations  allowed  to  contribute  to  the 
query.  Two  common  scopes  are  global  and  local.  A  query  with  a  global  scope  is 
evaluated  at  all  stations,  those  with  a  local  scope  are  only  evaluated  at  the  station  is¬ 
suing  the  query. 

As  an  example,  suppose  the  user  specifies  the  selection  condition  C  over  the  ob¬ 
ject  type  0.  The  global  query  is  simply 

set  arts  is  0  where  C; 

For  local  queries  the  definition  of  Station  is  altered  as  follows. 

Hpfine  object  type  Station  begin 

constituents; 

Station  -*  LocalObject-¥‘, 

mappings; 

LocalObject  :  MStation  Station-, 

constraints; 

object  type  of  Local  Object  is  Office  Object-, 


end 
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Here  we  have  defined  the  multivalued  constituent  LocaZObject  which  is  the  set  of  ob¬ 
jects  at  a  particular  station,  i.e.,  all  objects  below  the  station  in  the  hierarchy. 

Suppose  the  identifier  station  is  bound  to  the  user's  station.  The  local  query  is 

set  arts  is  a:  e  0  where 

C  andx  e  station:!/) cal  Object-, 

Now  suppose  the  same  selection  condition  is  specified  but  the  user  is  interested  in  ob¬ 
jects  residing  at  stations  whose  operators  earn  more  than  a  certain  amount.  Such  a 
query  could  be  answered  by 

set  OTIS'  is  ar  e  0  vrtiere 

C  and  x: At  St  ation:()peratedBy.  Salary  >  20000; 

Here  we  have  used  OperatedBy,  the  mapping  which  takes  one  from  a  station  to  an  em¬ 
ployee,  and  the  AtStation  mapping  which  gives  the  station  where  an  office  object  re¬ 
sides. 

As  a  second  example  of  the  translation  of  user  commands  to  object  operations, 
consider  the  move  command  used  in  Star  [30].  Assume  the  user  has  indicated  object 
z  (initially  displayed  in  template  tz)  is  to  be  moved  from  the  desk  to  the  outtray.  This 
is  accomplished  by  the  following  transaction 

tb^in 

erase  tx, 

remove  desk:  Sab  Part  isz; 
assert  outtray :Sab Part  is  z; 

tend 

A  more  complicated  variation  is  when,  instead  of  a  single  object,  a  set  of  objects  is 
moved.  Suppose  the  set  is  sx,  the  transaction  generated  is 

tbegin 

erase  fz; 
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for  X  in  sx  do 

remove  desk  :Sub Part  is  x; 
assert  out  tray :  Sub  Part  is  x; 

end 

lend 

Thus  one  can  imagine  the  scenario  where  a  set  of  objects  is  retrieved  by  a  query  emd 
then  collectively  transferred  with  a  single  move  command. 

5  Conclusions 

In  this  paper,  we  have  described  a  data  model  for  office  applications.  The  model 
is  object  oriented  and  has  been  influenced  by  the  abstraction  mechanisms  used  in 
conceptual  modelling  and  knowledge  representation.  Object  structure  is  specified  de- 
claratively  and  consists  of  a  property  hierarchy  and  constituent  associations.  Con¬ 
straints  are  expressed  in  a  procedural  manner  using  triggers  and  domain  definitions. 
The  allowable  data  types  include  audio,  image,  and  text  in  addition  to  those  tradition¬ 
ally  found  in  programming  languages.  Templates  can  be  defined  for  presenting  ob¬ 
jects  in  various  media. 

The  model  is  intended  to  represent  some  aspect  of  an  external  reality;  objects 
within  the  model  being  in  a  one  to  one  correspondence  with  objects  in  the  application 
domain.  This  should  be  compared  to  a  programming  language  approach  where  the 
mapping  between  external  objects  and  internal  representations  becomes  more  tenu¬ 
ous.  We  believe  that  a  data  model  can  provide  a  suitable  environment  for  office  infor¬ 
mation  system  implementation.  Operations  within  the  model  resemble,  at  a  high  lev¬ 
el,  the  operations  within  the  office.  Data  modelling  has  traditionally  been  concerned 
with  the  separation  of  data  from  the  programs  accessing  the  data.  In  our  context,  the 
model  avoids  the  necessity  of  embedding  the  semantics  of  office  objects  in  the  user- 
interface  software.  In  this  manner,  the  overhead  on  interface  design  and  development 
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is  lessened  and  various  interfaces  can  be  tested  for  user  acceptance. 

A  number  of  important  areas  are  beyond  the  scope  of  our  model.  One  such  area 
is  constraint  violation.  We  allow  constraints  to  be  expressed  at  different  levels  using 
domains,  triggers,  and  object  type  definitions.  What  constraints  may  be  violated,  and 
how  to  proceed  if  this  happens,  remains  problematic.  A  second  area  we  have  not  men¬ 
tioned  is  that  of  office  procedures.  Triggers  can  be  used  for  short  event-like  pro¬ 
cedures.  For  longer  activities,  in  particular  those  requiring  the  cooperation  and  coor¬ 
dination  of  many  stations,  a  full  fledged  procedure  specification  capability  is  needed 
[36].  Implementation  issues,  such  as  distribution  and  concurrency  control  have  been 
neglected  for  the  most  part.  However  many  of  the  techniques  used  in  distributed  da¬ 
tabase  s3rstems  may  be  applicable. 

Implementation  of  the  model  described  in  this  paper  has  so  far  been  concerned 
with  algorithms  for  the  object  operations.  A  program  has  been  developed  that  gen¬ 
erates  a  relational  schema  from  a  set  of  object  type  definitions  and  translates  object 
operations  to  relational  updates,  inserts  and  deletes. 

The  modelling  of  the  office  environment  is  part  of  a  larger  research  project  at 
the  University  of  Toronto.  Other  project  members  are  working  in  such  areas  as 
multi-media  interfaces,  the  integration  of  text  and  image  data  with  a  relational  data¬ 
base,  the  modelling  and  analysis  of  message  flow  in  the  office,  and  the  specification  of 
message  routing  and  processing. 
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ABSTRACT 

hnail  is  an  "intelligent  mail"  system.  Whereas  conventional 
mail  messages  consist  of  passive  text,  "intelligent  messages" 
(imessages)  are  programs  that  are  run  by  the  imail  receiving  pro¬ 
gram.  They  are  capable  of  not  only  delivering  information  but 
also  collecting  it,  and  may  dynamically  route  themselves  to  addi¬ 
tional  stations  depending  upon  responses  that  they  receive. 

This  paper  describes  a  prototype  imail  system  and  indicates 
future  directions  of  research. 


6,  1983 


inuiil  -  An  Intelligent  Mail  System 


John  Hogg 
Murray  Mazer 
Stelios  Ganwroulas 
Dennis  T^chritzis 

Computer  Systems  Research  Group 
University  of  Toronto 


1.  Introduction 

An  Office  Mformation  System  (OIS)  is  a  system  consisting  of  hardware 
resources  and  software  facilities  that  supports  the  automation  of  certain  office 
procedures.  An  electronic  mail  system  provides  support  for  communication 
among  the  (possibly  geographically  distributed)  roles  in  an  office  environment. 
Given  that  communication  is  extensively  involved  in  most  office  procedures, 
electronic  mail  systems  have  turned  out  to  be  indispensable  components  of 
Office  Information  Systems. 

A  role  in  an  office  environment  is  defined  to  be  either  a  person  or  a  func¬ 
tion  (e.g..  secretciry).  Communication  among  roles  in  the  office  has  in  past 
been  carried  out  by  means  of  passive  messages.  Traditionally,  a  message  (i.e..  a 
piece  of  text  conveying  some  information)  is  created  by  a  sender  and  is  shipped 
to  a  number  of  recipients.  A  message  can  only  convey  information;  it  cannot 
collect  information.  The  message  is  considered  to  have  carried  out  its  task 
once  the  recipients  have  read  it. 

A  message  can  also  be  viewed  in  a  different  way.  It  can  be  endowed  with 
intelligence,  namely  the  ability  to  accomplish  complicated  tasks,  such  as 


-3- 


collecting  responses  from  recipients,  routing  itself  to  recipients  according  to 
predefined  rules,  etc.  [VTTBl]. 

The  following  example  illustrates  the  use  of  intelligent  messages.  Suppose 
that  a  researcher  with  access  to  a  mail  system  wishes  to  establish  a  mailing  list 
of  other  workers  with  an  interest  in  his  particular  area.  The  mail  system  may 
possibly  be  running  on  machines  and  even  networks  that  the  sender  is  unaware 
of.  The  conventional  approach  would  be  to  issue  a  broadcast  message  to  all 
users.  This  implies  that  the  researcher  already  knows  a  superset  of  the  persons 
he  wants  to  contact.  With  an  intelligent  active  mail  system,  however,  the 
reseeircher  can  compose  an  imessage  asking  "Are  you  interested  in  communi- 
cating  on  the  subject  of  The  response  is  collected.  The  active  message 

can  then  go  on  to  ask  "Who  else  do  you  know  that  might  be  interested?".  This 
response  is  also  stored  and  this  particular  session  is  concluded.  The  active 
messcuge  forwards  itself  to  any  new  addresses  from  the  list  of  names  given. 
When  all  recipients  have  responded  to  the  questionnaire  (or  not  responded 
within  some  time  limit)  and  no  new  names  are  left,  the  message  terminates, 
returning  its  results  to  the  original  sender.  To  start  the  process,  the 
researcher  need  only  specify  a  short  initial  list  of  likely  users. 

This  paper  describes  the  design  and  implementation  of  a  mail  system 
(hereafter  called  imail)  capable  of  handling  intelligent  messages.  Within  our 
fraunework,  an  intelligent  message  (hereafter  called  an  imessage)  is  a  program 
(as  opposed  to  text)  and  it  is  run  (as  opposed  to  being  read)  by  its  recipients. 
We  suggest  that  the  notion  of  the  imessage  is  quite  promising  and  potentially 
useful  in  a  variety  of  environments. 

Section  3  explains  the  basic  features  that  characterize  an  imessage.  Sec¬ 
tion  3  is  an  overview  of  how  imessages  are  sent  and  received  from  the  user’s 
point  of  view.  The  imail  specification  language  is  described  in  Section  4.  Sec- 
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tion  5  outlines  some  sample  imcssages. 

The  following  terminology  will  be  used  throughout  the  subsequent  sections 


of  this  paper. 

imail: 

intelligent  mail  system. 

Imessage: 

intelligent  message. 

sender: 

person  that  creates  and  unleashes  an  imessage. 

recipient: 

person  that  receives  an  imessage. 

question: 

a  question  posed  by  the  imessage  to  a  recipient. 

response: 

a  response  given  by  a  recipient  when  presented  with  an 
imessage  question. 

shipping: 

forwarding  of  an  imessage  to  a  number  of  recipients. 

dynamic  routing: 

routing  carried  out  according  to  the  imessage  state. 

termination: 

completion  of  the  imessage  tour. 

results: 

assembled  responses  to  an  imessage  returned  to  the 
sender  upon  imessage  termination. 

Ivnail  presently  runs  in  a  centralized  manner  under  the  Berkeley  UNIX* 
operating  system  [R1T78]  on  a  VAX  11/760.  In  this  configuration,  the  role  of 
addresses  is  played  by  the  login  ids  of  the  users'  UNIX  accounts. 

A  user-friendly  language  for  imessage  specification  has  been  defined  and 
implemented.  TTiis  could  have  been  compiled  directly  to  executable  code  or 
interpreted  each  time  an  imessage  was  run.  The  simplest  and  most  flexible 
approach,  however,  was  to  translate  to  an  intermediate  language  and  interpret 
this.  The  logical  language  to  translate  to  was  the  UNIX  "C  shell"  csh  [JOY80].  dh 
is  a  powerful  language  with  the  constructs  required  for  our  purposes,  and  by 
using  it  we  avoided  having  to  build  a  special  interpreter. 

The  programs  that  constitute  the  Imail  system  are  written  in  the  C  pro¬ 
gramming  language  [KER78].  The  imail  language  translator  was  written  with 
the  aid  of  the  YACC  parser  generator  [JOH75]  and  the  LEX  lexical  analyzer  gen¬ 
erator  [LES75]. 


♦  UNIX  is  a  trademark  of  Bel]  [jaboratories. 
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2.  Imessages 

An  imessage  is  a  'program  thal.  is  run  by  the  recipient.  This  property 
enables  the  imessage  to  accomplish  da5dhing  that  a  program  can  do  within  the 
limits  of  the  language  used.  Through  1  his  language,  the  creator  of  the  imessage 
can  incorporate  in  it  rules  which  will  govern  the  interaction  of  the  imessage 
with  its  recipients  at  imessage  running  time. 

Any  response  to  a  conventional  message  must  be  created  by  the  recipient 
and  shipped  to  the  sender  manually,  as  a  separate  message.  However,  an  imes¬ 
sage  can  collect  responses  provided  by  its  recipients,  store  them  appropriately, 
and  eventually  make  them  available  to  its  sender.  The  sender  may  define  arbi¬ 
trary  conversations  between  the  imessage  and  its  recipients.  Furthermore,  a 
particular  question  incorporated  into  the  imessage  code  may  or  may  not  be 
actually  posed  tc  a  particular  recipient,  according  to  the  current  imessage 
state.  Some  of  the  factors  that  could  potentially  define  the  imessage  state  are 
the  following: 

a.  the  identity  of  the  current  recipient. 

b.  the  set  of  recipients  already  visited. 

c.  responses  to  previous  questions  given  by  the  current  recipient. 

d.  responses  given  by  other,  oreviously  visited  recipients. 

e.  current  date  and  time, 

f.  some  external  system  state  determined  by  running  a  procedure. 

As  more  factors  are  used  to  determine  the  imessage  state,  the  imessage 
appears  increasingly  intelligent  to  the  user.  Obviously,  the  imessage  has  con¬ 
siderable  flexibility  as  to  how  it  will  interact  with  each  of  its  recipients. 

Response  manipulation  such  as  tallying  or  performing  statistical  tests  can 
either  be  done  "on  the  fly"  as  each  reply  is  received,  or  at  the  very  end  when  all 
recipients  have  been  visited.  The  fo*^aier  approach  allows  the  imessage  sender 
to  know  more  about  his  or  her  results  sooner,  and  thus  to  exercise  more  con¬ 
trol  over  where  the  imessage  goes  and  what  it  does.  Complicated  processing. 


however,  may  be  easier  to  do  or  the  collected  data,  hnail  allows  both  possibili¬ 
ties.  Within  the  body  of  an  imf.*ssage  script  the  replies  given  by  the  recipient 
are  all  accessible,  and  the  language  allows  simple  arithmetic  expressions.  How¬ 
ever,  all  replies  and  other  variables  are  also  stored  for  each  imail  session. 
Thus,  when  an  imessage  terminates,  the  data  collected  may  be  massaged  in 
whatever  manner  the  original  sender  desires. 

Conventional  mail  systems  require  the  sender  to  specify  all  of  the  reci¬ 
pient  addresses  at  message  sending  time.  This  kind  of  routing  is  static  in  the 
sense  that  the  message  will  visit  only  a  set  of  addresses  that  have  been  expli¬ 
citly  specified  by  the  sender  beforehand.  The  message  dies  after  reaching  its 
initial  recipients,  and  does  not  subsequently  visit  further  recipients. 

An  imessage,  however,  can  route  itself  dynamically,  i.e.,  in  response  to  its 
interactions  with  its  recipients  [TS1B3].  [MAZ83].  Initially,  the  imessage  must 
be  given  .at  least  one  recipient  address.  After  this,  future  destinations  may  be 
added  as  a  result  of  an  imail  session.  'ITiese  destinations  may  be  "constants" 
specified  by  the  initial  sender  when  the  imessage  is  created  but  only  used  as 
destinations  if  certain  criteria  are  met  during  a  session.  Alternatively,  they 
may  be  given  as  responses  by  a  recipient  and  thus  be  totally  unknown  to  the 
sender.  A  third  possibility  (which  is  not  currently  supported)  is  to  have  some 
arbitrary  function  (e  g.,  a  database  access)  supply  destinations. 

It  should  be  noted  that  sex  eral  de-dinations  can  be  shipped  to  in  parallel. 
Only  one  copy  of  the  message  exists  on  the  present  centralized  system  and  thus 
a  primitive  locking  scheme  can  be  used  to  avoid  concurrency  problems. 

Upon  satisfaction  of  certai.n  conditions  specified  by  the  sender  (called  ter- 
minaiion  conditions'),  an  imessiige  is  considered  to  have  completed  its  tour.  At 
that  time,  care  is  taken  by  the  system  so  thal 
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a.  rssponses  collected  from  recipients  {resvlts)  will  become  available 
to  the  sender,  and 

b.  the  structures  and  data  that  made  up  the  imessage  are  cleaned  up. 

An  imessage  may  terminate  due  to  one  of  the  following  conditions: 

a.  no  more  recipients  are  left  to  be  visited. 

b.  the  imessage  has  effected  a  predefined  number  of  visits. 

c.  an  explicit  "terminate”  statement  is  executed  within  the  message. 

d.  an  error  occurred  in  the  execution  of  the  message. 

In  the  current  implementation,  Imessage  files  are  kept  centrally  in  a  dedi¬ 
cated  UNIX  account.  For  each  imessage,  these  files  record  information  such  as: 

a.  the  .(message  code, 

b.  tiie  addresses  of  the  recipients  to  be  visited  by  the  imessage, 

c.  the  addresses  of  the  recipients  already  visited  by  the  imessage, 

d.  the  responses  of  the  recipients  to  imessage  questions,  etc. 

Note  that  the  system  retains  a  single  copy  of  every  imessage  file.  This 
means  that  there  are  boi.h  security  and  coordination  problems  to  be  overcome 
since  imesseges  should  be  accessible  only  to  one  valid  recipient  at  a  time. 
Coordination  was  solved  using  a  simple  lock  so  that  only  one  recipient  can  run 
an  imessage  at  a  given  time.  Security  was  obtained  by  a  feature  of  UNIX  which 
allows  the  eflective  id  and  thus  the  permissions  of  a  program  user  to  be  set  to 
the  owner  of  the  program.  Access  to  the  tmail  files  can  then  be  restricted  to  a 
special  imail  login,  and  other  users  can  only  access  these  files  through  imail. 

The  inriportance  of  adequate  security  in  an  imail  system  should  not  be 
underrated.  Conventional  mail  is  passive  and  thus  can  do  little  damage.  An 
imessage  is  a  program,  and  its  contents  are  unknown  to  the  recipient  who  runs 
it.  If  the  code  is  handcrafted  by  the  sender  instead  of  being  generated  by  a  sys¬ 
tem  program  (and  therefore  certified  harmless),  the  recipient  would  be 
justified  in  being  wary;  another  user  with  an  unconventional  sense  of  humour 
could  send  ai  imessage  which  deletes  all  the  recipient's  files. 
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3.  Using  ImaLl 

linaiL  is  received  by  invoking  the  imml  program  with  no  arguments.  A  list 
of  imessage  headers  (giving  the  message  subject,  sender  and  date)  is  printed 
out  and  the  recipient  can  choose  to  run  any  of  them.  If  an  imessage  is  not  run 
immediately  it  will  remain  in  the  recipient’s  mailbox  and  the  header  will  be 
displayed  at  each  "receive"  invocation  of  ima.il  until  it  is  terminated  by  some 
user  action  or  external  event  such  as  a  timeout.  Alternatively,  a  recipient  may 
choose  to  delete  an  imesscige.  In  this  case  it  disappeeirs  and  will  not  bother  him 
or  her  again. 

When  an  imessage  is  invoked,  a  process  is  started  up  that  runs  the  imail 
script.  The  recipient  sees  a  series  of  questions  appear  on  the  screen.  After 
each  question  an  answer  is  collected;  should  it  be  invalid  (e.g..  "None"  in 
response  to  a  request  for  a  number  of  logins),  the  nature  of  the  response 
expected  is  explained  and  another  reply  is  requested.  At  any  point,  the  reci¬ 
pient  may  quit  the  session,  in  which  case  the  fact  of  quitting  will  be  stored  but 
the  responses  given  up  to  that  point  will  be  discarded  The  imessage  will  be 
placed  back  ni  the  recipient's  mailbox  and  remain  there  until  it  is  run  to  com¬ 
pletion,  terminated  or  deleted. 

An  imessage  is  created  by  writing  a  script  file  in  the  same  way  that  csh 
command  files  are  made  in  um,  The  language  used  is  described  in  the  follow¬ 
ing  section,  ’^o  send  the  imessage  the  imail  program  is  invoked  with  a  list  of 
initial  addresses. 

4.  The  Imail  l^guage 

Imessages  are  programs  and  must  therefore  be  described  using  some  pro¬ 
gram  specification  language.  This  could  be  a  menu  system,  which  would  have 
the  advantage  of  being  comparatively  easy  for  non-programmers  to  use.  For 
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ease  of  implementation,  however,  we  decided  to  use  a  small  programming 
langucige.  It  is  simpler  than  most  te);t  editors,  so  learning  how  to  use  imail 
should  not  be  too  difficult.  On  top  of  this  language  special-purpose  imessages 
can  be  implemented  using  a  menu  appr  oach. 

An  imessage  is  made  up  of  a  series  of  gussHo'ns  (optionally  preceded  by  a 
subject  eaid  initializrJions)  each  followed  by  a  yet  and  associated  actions.  A 
subject  is  a  line  starting  with  the  word  "subjec-t".  The  remainder  will  be 
displayed  in  the  imessage  header,  k  get  is  simply  a  line  stating  how  many  of 
what  type  of  response  to  accept  such  as  "get  1  number"  or  "get  2-3  logins"  or 
"get  words".  Kesponses  (and  other  vaiiables)  can  only  be  words,  numbers, 
logins  or  text.  ("Text”  is  zer  o  or  more  Imes  of  any  characters.)  Type  mixing  is 
not  edlowed.  This  makes  it  easier  to  avoid  errors  at  message  reception  time. 
Should  a  recipient  give  an  incorrect  number  of  responses  or  type  of  response 
he  or  she  wilt  be  given  an  explanatior.  of  the  kind  of  answer  expected  and 
reprompted  for  a  correct  reply.  (This  implicit  checking  is  done  by  the  imail 
runtime  environment,  so  the  sender  need  not  worrj'  about  it.) 

Actions  are  a  block  of  commands,  some  of  which  may  be  restricted  by  tests. 
A  test  is  a  pattern  or  a  numeric  expression  such  as  "^3  <  IQ  k  §?>  >  5".  ("#3"  is 
a  response  variable,  explained  below.)  Tiie  left  side  of  a  numeric  relation  may 
be  omitted  in  whiCh  case  the  response  for  the  current  question  is  used. 

An  interesting  feature  c*f  the  imail  language  is  the  way  that  constructs  are 
separated.  It  wa.s  felt  that  block  delimdors  ("^  .j"  or  "BEGIN.. .END")  are  not  obvi¬ 
ous  to  non-programmers  or  even  programmers;  it  is  generally  expected  that 
programmers  will  indent  their  code  to  highlight  control  structures.  "We  do  away 
with  almost  all  delimiters  and  instead  use  indentation.  Each  question  is  pre¬ 
ceded  by  a  line  starting  with  ">"  and  optionally  containing  a  label,  but  the  end 
of  the  questiori  text  is  indicated  by  the  ri(‘xt  line  (the  get)  starting  with  a  tab. 
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Lach  ge\  causes  the  Ic  be  assigned  to  a  response  variable  associated 


with  vhe  quc-;lior..  If  no  label  vvas  given  this  response  may  later  be  referred  to 


by  the  absol.ite  queslion  nuriber  preceded  by  e.g.  §12',  alternatively  the 
reiati/e  question  nunilxer  rriay  :>q  used.  e.g.  §-2.  If  the  question  was  labelled 
then  ihe  labs  I  name  may  be  uset^  instead,  e.g.,  §address. 

There  are  disc  local  and  alobal  variables.  The  former  may  be  initialized  at 
the  start  of  .m  ir-,\ oc'ation  but  cio  not  retain  their  values  between  invocations. 
They  are  this  anelogous  to  vm-ables  local  to  a  procedure  invocation.  Global 
variables  ma/’  be  initialized  wrien  the  message  is  created  and  exist  for  the  life 
of  the  imess.igo.  Ince.l  variabler  are  indicated  by  a  leading  "!"  and  global  veiri- 
ables  by  a  letidin';;  "?’ .  so  fniim-iices  and  ?numresponses  are  respective  examples 
of  each.  The  values  nf  all  vc.i  iab  os.  response,  local  and  global,  are  stored  at  the 
end  of  each  i  ivooacicn  for  the  render  to  process  as  required. 

There  is  also  a  sj'ecia]  ^o'b'  variable,  !me.  This  is  automatically  assigned 
the  current  r  ecipanl’d’  login  id  at  the  beginning  of  a  session. 

The  com  nands  aued  in  aji  t.ction  block  are  simple.  Each  command  starts 
with  o  keywc.  d  ar.d  the  enti  re  ii-ti  is  as  follows: 


prir  t 


Fr  rd  t  e  remainder  of  the  line.  If  the  line  is  simply 
"text,  ’  r-rint  the  following  unindented  lines. 


shif 


Ser.d  the  iniessage  to  the  following  people.  Arguments 
m  iy  be  valid  login.s  or  login  variables. 


unsiup 


If  the  following  have  been  mailed  the  imessage  but 
h.o.ve  not  yet  run  it,  delete  it  from  their  mailboxes. 


resnip 


Norma’ ly  an  imessage  is  not  sent  back  to  a  station 
that  it  has  already  been  run  at.  Reship  ships  to  a  reci¬ 
pient  even  if  the  imessage  has  previously  been  run  by 
him  or  her.  If  no  arguments  are  given,  all  the  stations 
that  the  imessage  has  previously  visited  are  shipped 
to  ag/un. 
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set 


The  full  command  is  "set  Cvary>  =  <expr>’',  where 
<vary>  is  a  local  or  global  variable  and  <expr>  is  a 
variable  or  a  simple  arithmetic  exT)ression.  Later  ver¬ 
sions  of  imail  may  also  alloy,  siring  expressions. 


terminate 


Terminate  the  entire  imessage  (not  just  tliis  invoca¬ 
tion). 


next 


Skip  over  zero  or  more  quescions  and  proceed  with  the 
question  given  as  an  argument,  (For  example,  if  "mar¬ 
ital  status"  is  "single",  skip  over  "spouse’s  name".)  The 
argument  may  be  euo  absolute  or  relative  question 
number  or  a  question  label. 


We  are  also  considering  allowing  calls  to  a  library  of  imail  routines  in  a 
later  version,  of  the  system.  However,  the  above  commands  seem  to  be 
sufficient  to  provide  the  power  and  flexibility  currently  required. 

5.  tmail  EbcaixpLes 

In  this  section  we  give  two  sample  imail  programs.  The  first  is  used  to 
track  down  a  paper  loaned  to  a  colleague  without  resorting  to  a  shotgun  broad¬ 
cast  approach.  The  second  pe''forms  a  Delphi  experiment  on  the  results  of  an 
upcoming  election. 

5.1  A  Paper  Chase 

The  following  is  a  simple  imessage  which  demonstrates  dynamic  routing. 
The*  sender  has  loaned  a  paper  to  one  of  his  col  leagues  who  has  passed  it  on  to 
someone  else  who  in  turn  has  given  it  to  a  third  person...  The  physical  way  to 
get  the  paper  back  is  to  visit  each  person  in  turn  and  find  out  what  he  or  she 
did  with  it.  The  conventional  electronic  mail  soh.iti(/n  is  to  send  a  message  to 
the  original  borrower  cuad  on  the  basis  of  the  reply,  send  out  another  message. 
This  is  repeated  until  the  paper  is  found. 

The  imail  approach  is  to  send  ofl  one  imessage  which  will  go  to  each  bor¬ 
rower  in  turn  until  the  holder  is  found  or  receipt  of  the  paper  is  denied,  In 
either  case  the  responses  will  be  sent  back  to  the  ov'ner  so  he  or  she  will  know 
whom  to  contact  personally.  An  imail  script  to  do  I  i is  is  given  below,  followed 
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by  an  explanation. 


set  login  ?laslholder  =  smith 

> 

Did  you  receive  the  paper  "Function  of  the  Orgasm  in.  Higher  Molluscs" 

from  ?lastholder  (y/n)? 
get  1  word 

n* 

print  Thank  you. 
terminate 

> 

Do  you  still  have  it  (y.'n)? 
get  1  word 

y* 

print  Please  return  it  to  John  Smith  ASAP, 
terminate 

>next 

To  whom  did  you  give  it  (login  or  <CR>  if  you  don't  know)? 
get  Ol  logins 

» I  » » 

print  Thank  you.  John  Smith  will  be  contacting  you. 
terminate 
default 

ship  iS^next 

set  ?lastholcer  =  !me 

> 

Thank  you! 

The  first  line  of  this  script  is  an  example  of  an  initialization.  In  initializa¬ 
tions  the  type  of  the  variable  (here  login)  must  be  specified.  In  later  set  actions 
the  type  will  be  taken  from  the  context. 

The  beginning  of  the  first  question  is  indicated  by  the  ">".  This  question  is 
displayed  on  the  recipient’s  terminal  with  "?lastholder"  being  replaced  by  the 
login  of  the  previous  recipient  or  in  the  case  of  the  first  recipient,  the  login  of 
the  sender  "smith".  A  one-wor'd  response  is  collected.  If  this  response  starts 
with  "n",  matching  the  pattern  shown,  "Thank  you."  will  be  printed  and  the 
entire  imessage  (not  just  tliis  invocation  of  it)  will  terminate.  All  responses  col¬ 
lected  to  this  point  will  be  returned  to  the  sender. 

If  any  other  response  is  given  the  second  question  text  will  be  displayed.  In 
this  case,  if  the  response  starts  with  "y",  "Please  return  it  to  John  Smith  ASAP." 
will  be  printed  and  the  imessage  will  terminate. 
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If  the  recipient  has  acknowledged  receiving  the  paper  but  does  not  still 
have  it,  he  or  she  is  asked  where  it  went  to.  The  response  must  be  an  empty 
line  or  one  valid  login,  and  the  imail  system  will  reprompt  until  a  valid  response 
is  supplied,  explaining  what  is  wrong  with  a  bad  response  (e.g.,  not  a  valid  login) 
until  a  correct  reply  is  given.  If  the  response  is  an  empty  line  it  will  matc  h  the 
pattern  between  the  quotes  (nothing)  and  the  imessage  will  terminate  after 
informing  the  recipient  that  a  more  personal  contact  will  be  forthcoming  0th- 
ervfise  the  message  must  visit  ai. other  recipient.  The  response  to  this  question 
could  have  been  referred  to  as  f}3,  but  to  illustrate  the  use  of  labels  we  have 
labelled  this  question  and  used  the  label  in  the  ship  action.  The  last  holder  of 
the  paper  is  then  updated  to  the  present  recipient  so  the  first  question  may  be 
printed  correctly  at  the  next  invocation.  This  is  an  example  of  the  use  of  the 
special  local  variable  !me. 

Finally,  a  polite  good-bye  is  printed  and  this  invocation  of  the  imessage 
ends. 

5.2,  A  l>elphi  Experiment 

A  Delphi  experiirient  is  an  iterative  survey  of  experts  to  obtain  a  consensus 
answer,  A  question  is  asked  and  each  respondent  gives  his  or  her  answer.  The 
results  of  the  survey  are  then  tabulated  and  sent  back  to  the  expert  population. 
Knowing  their  peers'  views,  the  experts  are  asked  to  answer  the  question  again. 
This  process  is  repeated  until  some  criterion  (e.g.  range  or  variance  of  replies) 
is  satisfied.  It  is  claimed  that  the  results  of  this  type  of  prediction  when  given 
to  a  suitable  body  are  surprisingly  accurate. 

A  sample  Delphi  experiment  could  be  run  to  predict  the  inflation  rate  for 
the  coming  year.  The  following  imail  script  will  do  this.  It  is  meant  to  be  sent 
to  a  number  of  "experts,"  say  executives  in  a  financial  institution.  Whenever  a 
minimum  number  of  them  have  re^plied,  a  new  average  value  and  variance  are 


-  33- 


calculated  and  those  whc  have  already  responded  are  again  sent  the  imessage. 
When  the  variance  becomes  sufTiciently  small,  the  survey  is  terminated. 


subject  A  Delphi  survey  of  inflation  rates 

set  number  ?n  =  0 

set  number  ?sum  ~  0 

set  number  ?sqsum  =  0 

set  number  ?maxvar  =  0,1 

set  number  ?itresps  =10 

set  number  ?avg  =  8.0 

> 

What  do  you  think  the  inflation  rate  for  next  yeair  will  be?  The  last  average 
pi'edicLion  was  ?avg. 
get  1  number 
set  ?sum  =  ?sum  +  ;^1 
set  ?sqsum  =  ?sqsum  +  *  §1 

set  ?n  =  ?n  -I-  1 
?n  ==  ?itresps 

set  ?avg  =  ?sum  /  ?n 

set  !var  =  ?sqsum  /  ?n  -  ?avg  ♦  ?avg 

set  ?n  =  0 

set  ?sum  =  0 

set  ?sqsum  =  0 

reship 

?var  <  ?ma:-cvar 
terminate 

This  example  is  shorter  than  the  last  one  but  more  complex.  In  this  case  a 
subject  is  specified  Several  global  variables  are  set  initially.  These  are  used  to 
record  the  number  of  recipients  visited  in  the  last  iteration  of  the  survey  and 
to  calculate  the  variance  of  the  responses  given.  Each  recipient  is  asked  just 
one  question:  the  inflation  rate  for  the  following  year.  This  response  §1  is 
added  to  a  running  sum,  its  square  is  added  to  a  running  sum  of  squares,  and 
the  number  of  visits  made  is  incremented.  When  the  number  of  visits  made 
becomes  equal  to  the  number  required  for  a  survery  iteration  the  equality  test 
will  hold  true  and  the  average  and  variance  will  be  calculated,  while  the  run- 
mng  sums  will  be  set  to  zero.  The  imessage  will  then  be  shipped  again  to  all 
recipients  that  it  was  originally  sent  to.  When  the  variance  becomes  less  than 
some  maximum  acccptF.ble  level,  the  survey  will  terminate. 

This  ime:ssdge  musi  be  given  initial  list  of  destinalions  that  contains  at 
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least  ?itresps  (i.e.,  ten)  names.  It  is  designed  to  be  sent  to  more  than  ten  reci¬ 
pients.  Then  if  several  of  them  delete  the  imessage  without  running  it  or 
merely  postpone  dealing  with  it  for  a  fair  while,  the  iteration  of  the  survey  will 
not  be  delayed. 

6.  Ck>Qcludiiig  Remarks 

Imail  is  an  on-going  project  and  we  intend  to  do  considerably  more  wcrk  on 

both  theoretical  and  practical  aspects  of  the  system. 

/ 

The  imail  language  is  still  not  entirely  satisfactory.  We  originally  intended 
it  to  be  simple  enough  for  use  by  non-programmers,  but  complicated  imes.sages 
(such  as  the  Delphi  experiment  explained  earlier)  require  what  can  only  be 
referred  to  as  "coding".  For  future  versions  of  the  system  the  entire  language 
will  be  overhauled. 

The  next  iteration  of  the  system  will  be  an  extension  to  handle  networks  of 
machines.  This  is  a  much  more  difficult  proposition  as  a  single  copy  of  the 
imessage  is  no  longer  sufficient  and  communication,  coordination  and  con¬ 
sistency  problems  must  be  dealt  with,  'this  will  require  some  theoretical  under¬ 
standing  and  modelling  of  imessage  interaction  and  we  intend  to  do  further 
work  in  this  area. 

Once  an  imessage  is  sent  off,  the  originator  has  no  idea  of  where  it  is  or 
whom  it  has  visited  until  it  terminates.  The  next  feature  to  be  added  is  a  status 
querying  facility  that  will  allow  the  sender  to  inspect  an  imessage's  history  and 
the  data  that  it  has  collected.  At  the  same  time,  the  imessage  may  be  pulled 
from  some  recipients’  mailboxes  and  added  to  others,  The  sender  will  thus 
have  an  overriding  control  over  the  imessage's  routing. 

At  present,  imessages  only  accept  input  from  human  message  recipients. 
This  provides  a  very  restricted  window  on  the  world.  As  mentioned  earlier,  a 
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libriry  of  iniail  routines  may  be  a  future  imail  extension.  While  some  would 
simoly  manipulate  data  obtained  from  recipients,  others  could  use  different 
sources  of  information  such  as  a  database.  Since  imail  is  at  present  a  close 
ana'ogue  of  conventional  electronic  mail,  human  action  (i.e.,  running  the  imes- 
sage)  would  still  be  required.  In  the  long  term,  however,  a  system  where  the 
imail  is  first  handled  by  a  station  process  could  be  envisioned.  If  no  human 
knowledge  or  explicit  permission  is  required,  an  intelligent  message  could  then 
go  f*om  station  to  station  interacting  with  intelligent  imail  handlers  in  order  to 
extract  Infor  mation  from  multiple  databases! 


-  16- 


7.  References 

[J0H75]  S.  C.  Johnson,  Yanc:  Yet  Another  Compiler  Compiler,  Comp.  Sci.  Tech. 
Rep.  No.  32,  Bell  Laboratories.  Murray  Hill,  N.J..  U.S.A. 

[JOY80]  W.  Joy,  An  Introduction  to  the  C  Shell,  UNIX  Programmer’s  Manual,  Vol. 

2c,  Department  of  Electrical  Engineering  and  Computer  Science, 
University  of  California,  Berkeley,  U.S.A. 

[KER78]  B.  W.  Kernighan  and  D  M.  Ritchie,  The  C  Programming  Language, 
Prentice-Hall,  N.J.,  U.S.A. 

[LiES75]  M.  E.  Lesk  and  E.  Schmidt,  Lex  -  A  Lexu:al  Analyzer  Generator,  Comp. 
Sci.  Tech.  Rep.  No.  39,  Bell  Laboratories,  Murray  Hill,  N.J.,  U.S.A. 

[MAZ63]  M.  S.  Mazer,  The  Stpecification  of  Routings  in  a  Message  Management 
System,  M.Sc.  Thesis,  Department  of  Computer  Science,  U.  of  Toronto, 

[RIT76]  D.  M.  Ritchie  and  K.  Thompson,  The  UNIX  Tirne- Sharing  System,  Bell  Sys¬ 
tems  Technical  Journal,  Vol.  57,  No.  6  (July-August  1978). 

[TSI83]  D.  Tsichritzis,  ’’Message  Addressing  Schemes,"  companion  paper  in  this 
report. 

[VIT81]  J.  Vittal,  "Active  Message  Processing:  Messages  as  Messengers,"  in 
Computer  Message  Systems,  R.  P.  Uhlig  (editor),  North-Holland. 


Using  Objects  lo  Implomenl  OfTice  lYocedures  ♦ 


John  Mooney 
Oscar  Nierstrasz 
Dennis  Tsichritzis 
Ken  Twaites 

Department  of  Computer  Science 
University  of  Toronto 
Toronto,  Ontario,  MSS  lAl 


ABSTRACT 

Office  information  systems  (OISs)  provide  facilities  for  automatically  triggering 
procedures  when  certain  conditions  become  true.  Such  S3^tems  are  character¬ 
ized  by  a  high  degree  of  p  irallel  activity.  Traditional  programming  environ¬ 
ments  do  not  readily  capture  this  sort  of  behaviour.  This  makes  building  an  OIS 
a  difficult  and  time-consuming  process.  "Objects"  are  entities  with  contents 
and  a  set  of  rules  describing  their  use.  We  are  implementing  an  object-based 
programming  system.  We  tKdieve  that  objects  are  a  useful  primitive  for  design¬ 
ing  and  buildxng  OISs  quickly. 


1.  Introducticm 

Automation  in  an  OIS  is  enabled  by  permitting  events  to  trigger  other 
events,  'he  receipt  of  a  certain  kind  of  message,  for  example,  may  trigger  a 
procedur  i  which  automatically  reads  the  message  and  responds  to  it.  The  crea¬ 
tion  or  modification  of  any  object  may  also  trigger  an  event.  By  specifying 
exactly  what  situations  may  .rigger  an  event  a  user  passes  the  responsibility  of 
firing  it  to  the  system.  What  distinguishes  an  electronic  office  from  a  physical 
office  is  that  in  it  we  may  implement  "intelligent"  office  objects,  Such  objects 
may  be  passive  and  merely  constrain  their  appearance  or  range  of  values,  or 
they  may  be  active  and  initiate  more  involved  office  procedures.  These  pro¬ 
cedures  need  not  be  explicitly  called  in  all  cases.  Instead,  one  might  ask  for  an 
event  to  l>e  triggered  whenev^er  a  particular  situation  arises,  without  indicating 


♦  A  ver.sion  of  this  paper  has  been  presented  at  the  1963  CIPS  conference. 


Using  Objects  to  Implement  Office  Procedures 


what  other  events  might  possibly  be  responsible. 

The  term  object  is  a  familiar  one  but  it  has  acquired  many  interpretations. 
It  suggests  at  once  a  collection  of  similar  concepts:  abstract  data  types,  intelli¬ 
gent  messages,  modules,  actors  [Hewi77,  BySJ82],  boxes  [deJoBO],  data  frames 
[EmblBO],  automatic  procedures  [TRGHBl]  and  Smalltalk  objects  [BYTE81]. 
Rather  than  invent  a  new  word,  we  will  try  to  present  a  simple  definition  of 
"object"  that  adequately  captures  its  vernacular  usage  and  is  also  powerful 
enough  to  model  real  object-based  systems. 

We  are  currently  implementing  an  object-based  system  at  the  University  of 
Toronto,  It  is  being  written  in  the  C  programming  language  on  a  VAlv-1 1/780 
running  the  UNIX  operating  system.  The  design  and  implementation  of  the  pro¬ 
ject  is  divided  into  two  major  parts  —  the  object  manager  and  the  user  inter¬ 
face.  The  object  manager  identifies  fireable  events,  and  fires  the  rules  of  each 
of  the  participeints  of  the  event.  The  user  interface  enables  the  user  to  define 
new  object  classes  and  interact  with  existing  object  instances  through  the  use 
of  a  special  "user  object". 

2.  An  object-based  system 

An  object-based  system  (OBS)  enables  one  to  represent  physical  objects 
within  a  computer.  It  allows  users  to  define  classes  of  objects  with  contents 
resembling  database  relations  and  behaviours  resembling  bodies  of  associated 
code,  A  behaviour  consists  of  rules  for  the  creation,  transformation  and  des¬ 
truction  of  objects.  An  object  behaves  as  though  it  is  always  watching  for  a 
triggering  condition  to  become  true. 

An  "object"  is  a  thing  -  something  with  an  identity.  Objects  can  be  parti¬ 
tioned  into  groups  of  similar  objects  (chairs,  desks),  and  they  have  a  set  of  pro¬ 
perties  which  makes  them  unique  (wooden  classroom  chair,  comfy  chair  with 
leather  upholstery).  Objects  also  have  a  behaviour  which  captures  their 


Usin^  Objects  to  Implcraent  OCBce  Procedures 


relationship  to  other  objects.  An  object  "knows"  its  behaviour  and  is  responsi¬ 
ble  for  it. 

Objects  ('.an  be  partitioned  into  classes  on  the  basis  of  some  reasonable 
grouping  —  chairs,  bicycles,  presidents.  Objects  in  the  same  class  are  referred 
to  as  instanct’.s  of  that  object  class.  Instances  are  characterized  by  their  con¬ 
tents  —  a  set  of  instance  variables  that  retain  their  values  between  the  firing  of 
events.  Associated  with  an  object  instance  is  its  behaviour,  a  set  of  rules  that 
use  the  instance  variables  and  make  them  available  to  other  objects. 

A  specification  for  a  trivial  object  class  called  secret  follows.  It  stores  a 
secret  mcssa^^e  and  a  key  to  unlock  the  message.  Anyone  who  knows  the  key 
can  obtain  the  message.  When  the  message  is  disclosed,  the  object  instance 
self-destructs.  The  object  is  described  using  a  specification  language  as  out¬ 
lined  in  the  appendix. 

secret:  ob  ecf| 

/*  instance  variable  declarations  */ 
ms/'.  key  ;  string, 
owiier  :  user, 

/*  I'ules  */ 
alpha(m,k)^ 

/*  only  users  may  create  secrets  */ 

~  .  iLser, 
m,  k  :  siring, 

/*  conditions  */ 
m  ""; 
k  ""; 

msg  m; 
key  <-  k; 
owner 
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omega(k)| 

~  :  user; 
k  ;  string; 

/♦  if  key  matches  */ 

/*  return  msg  */ 

/♦  then  self-destruct  */ 

k  =  key; 

i(msg) 

The  secret  object  has  three  instance  variables  in  its  contents:  msg,  key  and 
oumer.  It  has  two  rules  in  its  behaviour:  alpha  and  omega,  alpha  and  omega  are 
reserved  words  for  rules  that  create  and  destroy  object  instances.  Any  other 
rules  would  apply  to  instances  that  have  been  created  but  not  yet  destroyed. 

is  a  reserved  word  that  identifies  another  object  invoking  that  rule,  is 
another  reserved  word  meaning  "myself”. 

kuser  object  could  automatically  obtain  these  messeiges  with  the  following 

rule; 

getmsgl 

/*  no  ~  variable;  getmsg  is  */ 

/*  triggered— not  explicitly  called  */ 

s  :  secret; 

TRUE  is  a  boolean  constant 
ready  =  TRUE; 

save  ♦-  s.omega(key); 
ready  *-  FALSE; 

I 

ready,  save  and  key  are  instance  variables  of  the  user  object.  The  getmsg  rule 
can  only  fire  if  the  ready  variable  is  set  to  TRUE.  This  prevents  getmsg  from 
firing  repeatedly  and  destroying  its  saved  messages.  Whereas  the  alpha  and 
omega  rules  of  the  secret  object  must  be  explicitly  called,  the  getmsg  rule  may 
be  fired  automatically  whenever  there  is  a  secret  object  with  a  matching  omega 
rule.  For  that  reason,  the  getmsg  rule  accepts  no  parameters  and  returns  no 
value. 
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An  object’s  ac quaint ancp.  is  another  object  that  it  knows  about,  Acquain¬ 
tances  communicate  by  invoking  rules  in  each  other’s  behaviours.  The 
acquaintance  variable  in  the  getmsg  rule  is  s.  The  alpha  and  omega  rules  have 
only  the  ~  acquaintance  —  the  object  invoking  the  rule.  The  getmsg  rule  has  no 
invoking  acquaintance. 

A  rule  may  only  fire  if  all  the  conditions  it  contains  are  true.  A  rule  is 
active  if  the  conditions  on  its  instance  variables  alone  are  true,  getmsg  is  only 
active  if  ready=TRUE.  alpha  and  omega  in  the  secret  object  are  always  active  — 
there  are  no  conditions  on  contents,  only  on  vedues  passed  by  acquaintances. 

Specialization  can  be  a  useful  tool  in  defining  new  classes  that  are  derived 
from  existing  classes.  A  sub-class  identifies  a  special  case  of  the  existing  class 
which  requires  some  additional  attention.  A  sub-class  may  be  defined  by  speci¬ 
alizing  its  superclass’  contents  or  behaviour.  Contents  may  be  specialized  by 
adding  new  instance  variables  or  by  restricting  the  domain  of  existing  ones. 
Behaviour  may  be  specialized  by  adding  new  rules  or  by  modifying  existing 
rules. 

2,1.  Events 

An  event  is  a  collection  of  object  instances  and  a  collection  of  rules  apply¬ 
ing  to  those  object  instances.  The  objects  in  the  collection  are  called  the  parti¬ 
cipants  of  the  event.  All  acquaintances  mentioned  in  the  rules  of  the  event 
must  belong  to  the  set  of  participants.  From  the  example  in  the  previous  sec¬ 
tion,  the  getmsg  rule  and  the  omega  rule  together  with  the  two  objects  involved 
would  constitute  an  event. 

A  rule  in  an  event  is  fireable  if  all  the  conditions  in  the  rule  are  true.  Fir¬ 
ing  a  rule  consists  of  executing  statements  within  the  rule.  Before  any  rule  in 
an  event  can  fire  there  must  be  unanimous  agreement.  This  means  that  all  the 
the  event  must  be  fireable.  At  this  point  the  event  itself  may  be  fired 
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and  the  contents  of  the  objects  participating  in  the  event  may  be  updated 
according  their  behaviour.  If  any  rule  in  an  event  is  not  fireable  then  nothing 
happens.  An  event  here  resembles  an  event  in  a  Petri  net  [Pete77]:  the  con¬ 
junction  of  all  the  conditions  in  the  rules  involved  in  the  event  must  be  true  for 
the  event  to  fire.  An  event  is  also  indivisible  in  the  Petri  net  sense.  The  entire 
event  must  fire  or  nothing  happens. 

3.  Office  procedures 

An  office  procedure  is  a  program  for  accomplishing  a  particular  task.  Typi¬ 
cally  such  tasks  require  the  manipulation  of  some  set  of  physical  objects  (paper 
forms,  books,  telephones,  pencils),  some  clearly  defined  actions,  some 
decision-making,  and  some  information-gathering  and  waiting.  We  propose  that 
objects,  as  they  are  described  above,  are  a  natural  choice  for  implementing 
office  procedures  on  a  computer. 

One  may  define  an  office  procedure  to  accomplish  a  simple  one-time  task 
like  modifying  some  field  on  a  form,  or  to  handle  a  large-scale,  ongoing  task  like 
inventory  control.  In  the  first  case  the  office  procedure  would  be  handled  by  a 
single  event,  perhaps  involving  only  one  rule  in  a  single  object.  A  single  event 
would  be  appropriate  because  the  task  is  logically  indivisible;  it  is  not  composed 
of  smaller  subtasks  which  may  succeed  or  fail.  For  the  same  reason  the  crea¬ 
tion  of  a  form  is  an  indivisible  task  even  though  it  may  involve  the  filling  in  of 
several  fields.  The  form  is  either  created  or  it  is  not  created.  It  is  not  possible 
to  have  a  partially  created  form.  If  it  is  the  intention,  however,  to  allow  the 
creation  of  a  form  with  some  or  all  of  its  field  blank,  then  this  task  must  be  bro¬ 
ken  into  its  indivisible  components.  The  first  subtask— the  actual  creation  of 
the  form  object— would  still  be  indivisible,  however. 

In  the  second  case,  a  large-scale  office  procedure  would  have  to  be  broken 
into  its  indivisible  steps.  Every  step  which  must  succeed  entirely  or  fail 
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entirely  would  correspond  to  the  firing  of  a  single  event.  Waiting,  information¬ 
gathering  and  decisions  that  influence  the  control  flow  of  the  procedure  are 
modelled  by  conditions  within  the  rules  that  make  an  event  flreable  or  not.  The 
specification  of  a  procedure  is  distributed  across  the  rules  of  the  objects 
involved. 

One  has  the  option  of  building  a  procedure  out  of  objects  that  talk  directly 
to  one  cinother  (order  forms  talk  directly  to  inventory  records  and  customer 
records)  or  creating  intermediate  objects  that  coordinate  the  others  (a 
"fillorder”  procedure  collects  the  inventory  form,  the  order  form  and  the  custo¬ 
mer  record,  then  fills  the  order).  The  first  approach  is  preferable  if  one  wants 
to  limit  for  all  time  how  the  objects  involved  in  the  procedure  are  to  be  used. 
The  procedure  is.  in  a  sense,  insulated  from  the  rest  of  the  system,  because  the 
objects  involved  are  incapable  of  communicating  with  any  other  object  classes. 
The  second  approach  is  more  flexible  if  future  applications  that  make  use  of 
these  objects  are  anticipated  Each  object  is  provided  with  a  set  of  rules  which 
a  wide  set  of  object  classes  can  access.  The  objects  involved  are  more  passive 
in  nature.  Events  are  brought  together  by  "procedure  objects"  that  collect  the 
other  objects  and  invoke  rules  within  them. 

Localized  intelligence  is  the  kind  that  applies  to  the  contents  of  one  object 
alone,  such  as  the  fields  of  an  intelligent  form.  Objects  are  capable  of  model¬ 
ling  a  wide  variety  of  important  field  t)^es.  [Geha82]  identifies  most  of  them. 
For  example: 

A  virtual  field  is  one  whose  value  is  computed  but  never  stored: 

total^ 

~  ;  object', 

t  :  integer', 

t  <-  price  X  quantity; 

l(t) 

Since  the  only  access  to  an  object’s  contents  is  through  its  rules,  it  is  abso- 
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lately  transparent  whether  a  field  is  virtual  or  not. 

Certain  standard  operations  can  also  be  easily  accommodated.  Create  and 
destroy  operations  are  accomplished  by  an  object's  initial  and  final  rules. 
Retrieval  involves  nothing  more  than  restricting  one’s  acquaintances  by  plac¬ 
ing  a  condition  in  a  rule: 

floyboss^ 

/♦  any  object  can  ask  */ 

/*  who  your  boss  is  */ 

~  :  object, 

m  :  manager-, 

/*  find  the  right  manager  */ 

m.name()  =  boss; 

i(ni): 

If  boss  is  a  variable  containing  your  boss'  name,  then  the  condition 
•m.najneQ-boss  guarantees  that  m  is  the  desired  manager  object. 

Editing  operations  have  already  been  discussed.  Any  rule  may  specify  the 
conditions  under  which  an  instance  variable  may  be  modified.  The  niceties  of 
editing  and  displacing  objects  are  the  job  of  the  user  interface,  and  are  not  part 
of  the  object  model. 

Mailing  e^nd  printing  operations  present  minor  difficulties  in  that  they  deal 
¥ith  entities  not  inherent  to  the  object  model,  namely  machines  and  printers. 
Objects  limit  their  scope  by  placing  conditions  on  their  acquaintances.  One 
may  model  ownership  by  explicitly  including  an  owner  or  location  field  in  every 
object.  The  set  of  all  objects  would  then  be  partitioned  according  to  worksta¬ 
tions  or  machines.  The  operation  of  mailing  an  object  would  be  accomplished 
by  simply  firing  a  rule  that  changed  that  variable.  The  object  manager  would 
have  to  be  smart  enough  to  realize  that  changing  the  location  variable  of  an 
object  means  that  that  object  must  be  moved  from  one  machine  to  another. 
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Objects  are  also  able  to  capture  global  behaviour.  An  office  procedure  con¬ 
sisting  of  a  simple  sequence  of  steps  can  be  modelled  by  an  object  in  which  the 

steps  appear  as  rules  and  a  counter  is  used  to  keep  track  of  the  next  step  to  be 
fired. 

step„^ 

counter  =  n; 

counter  +  +  ; 

i 

Objects  can  simulate  finite  automata; 

rulcjt 

I 

state  =  j ; 
state  *-  j'\ 
state  =  I ; 
state  Z': 

I 

! 

A  state  variable  keeps  track  of  the  automaton's  state.  Each  rule  is  composed  of 
a  number  of  alternatives  that  describe  the  action  to  be  performed  in  each 
state,  and  the  appropriate  next  state  to  follow. 

Objects  can  also  simulate  (augmented)  Petri  nets  [Zism77]: 
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transitionil 

/♦  input  states  */ 

Staten  ]>  0; 
statefkj  >  0; 

/*  additional  conditions  */ 

/♦  actions  */ 

/  ♦  outputs  *  / 
state[l]  ++; 
state[m]  +  +  ; 

r 

In  all  of  the  above  cases,  it  is  the  object  manager’s  responsibility  to  detect 
when  a  rule  may  be  fired. 

4.  TTie  object  manager 

The  task  of  the  object  manager  in  an  OBS  is  to  manage  the  internal 
representation  of  objects.  This  entails  the  translation  of  object  class  definitions 
(or  modifications  to  them)  into  their  internal  representations,  and  the  manage¬ 
ment  of  object  instances  by  searching  for  and  firing  events.  Users  are  modelled 
by  a  special  "user  object"  implemented  by  the  user  interface,  which  presents 
objects  and  events  to  users,  interprets  user  requests,  and  communicates  with 
the  object  manager.  It  will  be  discussed  in  greater  detail  in  the  next  section. 

The  translation  of  object  instances  presents  no  special  difficulties.  The 
object  manager  need  only  generate  the  appropriate  data  structure  for  storing 
the  instance  variables  of  each  object  instance.  This  environment  can  be  imple¬ 
mented  using  relational  databases. 

Much  more  difficult  is  the  problem  of  translating  behaviours.  A  rule  may 
be  broken  down  into  several  parts.  There  are  conditions  and  actions.  Some 
conditional  may  bo  dotormituu:!  from  the  valia^s  of  the  instance  variables  alone, 
These  conditions  determine  whether  a  rule  is  active  or  not.  If  a  rule  is  not 
active,  it  is  certainly  not  fireable.  All  other  conditions  depend  on  values  sent  by 
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acquaintances,  and  hence  cannot  be  determined  until  an  event  is  constructed. 
It  is  therefore  very  useful  to  keep  track  of  which  rules  are  active  in  order  to 
simplify  the  task  of  constructing  events.  A  simple  bit  vector  can  be  maintained 
for  this  purpose  Whenever  a  rule  is  fired  that  modifies  some  instance  veiri- 
ables,  the  object  manager  must  check  whether  any  other  rules  have  been 
activated  or  deactivated  [H0NT8I].  Every  rule  must  then  keep  a  list  of  what 
new  rules  to  check. 

The  remaining  conditions  can  be  divided  into  conditions  on  the  invoking 
object  and  parameters  passed  by  it.  and  conditions  on  other  acquaintances  and 
values  returned  by  them. 

Actions  must  also  be  segregated.  Some  actions  set  temporary  variables  to 
be  used  in  calculations  or  to  be  passed  to  an  acquaintance.  Others  modify  the 
contents  of  an  object.  Those  statements  that  modify  an  object's  instance  vari¬ 
ables  must  not  be  executed  until  a  flreable  event  has  been  identified,  for  it  is 
these  statements  that  constitute  the  permanent  side  effects  of  firing  the  event. 
All  other  statements  "merely"  establish  conditions  or  aid  in  passing  values 
between  objects. 

Finally,  when  an  object  fires  a  rule,  it  may  not  only  activate  or  deactivate 
one  of  its  own  rules,  it  may  in  fact  effect  a  state  change  that  some  other  object 
was  waiting  for.  One  must  therefore  also  keep  track  of  who  may  be  invoking 
one’s  rules.  A  rule  that  becomes  active  becomes  available  to  another  object 
waiting  to  invoke  it  [HoNTBl]. 

The  object  manager  must  guarantee  that  every  fireable  event  eventually 
either  get  fired  or  become  disabled  by  the  firing  of  some  other  event.  It  is  not 
possible  to  guarantee  that  all  fireable  events  get  fired  because  two  events  may 
overlap  in  objects  that  may  only  participate  in  one  of  the  two.  If,  for  example, 
two  users  have  the  same  hsy  for  their  yQtinsy  rule,  then  a  ssevst  object  with  a 
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matching  key  could  only  disclose  its  msg  to  one  of  the  two  objects  since  the 
object  would  self-destruct  after  the  firing  of  the  first  rule,  We  assume,  in  cases 
like  this,  that  the  firing  of  either  p^^ent  is  equally  appropriate  for  accomplishing 
the  task  at  hand.  What  follows  is  a  scenario  that  informally  describes  the  algo¬ 
rithm  that  searches  for  and  fires  events, 

Initially  our  system  is  stable  and  free  of  objects,  A  stable  system  has  no 
fireable  events.  User  objects  may  be  created  through  the  use  of  the  user  inter¬ 
face.  Let  us  consider  the  case  where  we  have  a  stable  system  with  some  set  of 
object  instances  in  existence.  Spontaneously  some  event  fires.  This  event  is 
presumably  the  work  of  a  user  object,  v/hich  may  "improvise  rules"  not  in  its 
behaviour  and  may  spontaneously  change  state,  A  "clock"  object  may  also 
spontaneously  change  state,  as  may  any  object  that  speaks  to  the  outside  world. 

Because  an  event  has  been  fired,  the  system  may  no  longer  be  stable.  If 
some  new  event  has  become  fireable,  it  must  involve  one  of  the  participants  of 
the  last  event  fired.  Every  object  in  the  event  that  has  undergone  a  change  of 
contents  is  placed  on  a  queue  and  its  active  rule  list  is  updated.  Starting  at  the 
head  of  the  queue  we  take  an  object  and  try  to  construct  an  event.  We  take 
every  active  rule  in  turn  and  try  to  find  acquaintances  for  it.  If  the  rule  needs 
to  be  invoked,  we  must  first  look  for  an  invoking  acquaintance  with  an  active 
invoking  rule.  For  each  acquaintance  we  must  recursively  search  for  its 
acquaintances.  At  each  step  the  conditions  on  values  passed  between  objects 
must  be  checked. 

If  none  of  the  active  rules  of  the  object  yields  a  fireable  event,  we  remove 
the  object  from  the  queue.  Alternatively,  if  a  fireable  event  is  found,  we  fire  it 
and  add  those  objects  that  have  changed  contents  to  the  end  of  the  queue.  This 
process  is  continued  until  the  queue  is  emptied  and  the  system  has  st.ibilized. 
Although  there  can  be  no  guarantee  that  the  system  will  ever  stabilize  we  may 
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be  certain  that  every  fireable  event  is  found  aid  fired  or  is  deactivated  in  a 
finite  and  reasonable  amount  of  time. 

5.  The  user  interface 

An  OBS  might  be  created  in  which  all  interactions  eimong  objects  teike 
place  internally  and  there  is  no  user  input  to  the  system.  Objects  would  be 
defined  at  system  start-up  and  all  modification  of  object  classes  and  instances 
would  be  done  by  the  system  as  it  runs.  While  this  system  may  be  useful  in 
some  applications,  it  would  not  be  able  to  effectively  capture  the  complex 
interactions  between  people  and  office  procedures.  A  method  of  allowing  people 
to  dynamically  manipulate  object  classes  and  instances  and  to  send  and  receive 
messages  in  the  system  is  required. 

The  user  interface  to  an  OBS  must  allow  users  to  define,  modify  and  possi¬ 
bly  delete  object  classes,  and  it  must  enable  users  to  create  object  instances, 
communicate  with  them,  and  destroy  them.  Smee  the  second  function  may 
also  be  carried  out  by  other  objects,  it  is  natura'  to  present  this  portion  of  the 
user  interface  as  though  it  were  an  object  itself.  The  behaviour  of  this  "user 
object"  is  the  code  associated  with  the  interface  together  with  the  user’s  needs 
and  imagination. 

In  addition  to  this,  a  user  object  may  have  a  set  of  default  rules  to  handle 
its  automatic  behaviour  in  dealing  with  other  objects  that  wish  to  communicate 
with  it.  The  user  interface  needn  t  interrupt  the  user  to  satisfy  a  query  about 
the  user's  name,  for  instance. 

There  are  similarities  between  defining  and  modifying  object  classes  and 
creating  and  interacting  with  object  instances,  't  may  therefore  be  desirable  to 
model  object  class  definitions  as  objects  themselves,  thereby  enabling  objects 
to  create  new  object  classes.  In  an  existing  implementation,  this  would  be  a 
relatively  simple  jnalter  of  linking  the  code  that  creatc.s  new  object  instances 
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with  the  code  that  creates  new  classes.  The  difficulty  lies  in  deciding  on  an 
appropriate  definition  of  the  "objer't-class”  object  class.  At  present,  however, 
we  shall  not  consider  this  twist. 

The  manipulation  of  object  classes  involves  the  definition  of  new  object 
classes  and  the  changing  of  contents  and  behaviour  in  existing  object  classes. 
This  is  done  out  of  view  of  the  object  manager  and,  when  complete,  the  object 
maneger  is  informed  of  the  manipulation  by  causing  a  particular  user  object 
rule  to  become  active.  When  the  rule  is  fired,  a  token  string  representing  the 
memipulation  is  passed  to  the  memager  and  an  object  class  definition  in  the  sys¬ 
tem  is  created  or  updated. 

The  user  manipulates  an  object  class  by  editing  the  class  definition.  An 
object  class  name  is  entered  and,  if  the  class  exists,  the  current  definition  is 
edited.  If  the  class  does  not  exist,  a  new  class  is  created.  When  the  manipula¬ 
tion  is  complete,  the  definition  is  compiled  and  passed  to  the  object  manager. 

In  creating  a  class,  the  user  must  give  a  unique  class  name.  If  the  class  is 
a  sub-class  of  another  class,  the  user  must  specify  the  superclass.  The  con¬ 
tents  are  then  specified  as  zero  or  more  variables  and  their  types.  If  initial 
values  are  given  then  each  subsequent  instance  takes  on  these  values  when 
created.  If  no  variables  are  specified  then  the  class  behaves  like  a  function. 
The  behaviour  is  given  by  specifying  zero  or  more  rules,  each  with  a  unique 
rule  name  within  the  object  class.  Each  rule  is  comprised  of  an  optional  set  of 
acquaintances,  an  optional  set  of  conditions  and  an  optional  set  of  actions.  The 
actions  may  be  assignment  of  values  to  variables,  sending  or  receiving  of  mes¬ 
sages,  or  a  set  of  sub-rules. 

The  changing  of  an  object  class  involves  altering  the  class  definition.  Dele¬ 
tion  of  a  class  may  require  all  instances  of  the  class  to  be  first  deleted  or  it  may 
alternatively  result  in  the  class  definition  and  all  instances  being  deleted. 
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Instdnc^c  manipulaLion  involves  Iho  croaMon  and  changing  of  object 
instances.  Fhe  user  interface  must  provide  the  object  and  rule  names  and  the 
required  parameters.  It  may  guide  the  user  in  constructing  the  event  by 
displaying  a  template  which  the  user  may  Till  in,  or  it  may  expect  the  user  to 
explicitly  indicate  the  rule  to  be  fired.  For  example,  using  the  secret  object 
described  in  section  2.1,  to  create  a  jxew  instance  the  user  may  type 
secret.alpha(string ,  key).  Alternatively,  a  template  may  be  presented  to  the 
user,  who  is  expected  to  fill  in  values  for  string  and  key.  When  the  alpha  rule 
(the  initial  rule  which  creates  instances)  for  that  object  is  satisfied,  the 
prepared  event  is  presented  to  the  object  manager  so  that  the  newly  created 
object  can  be  stored,  and  other  objects  may  communicate  with  it. 

Changes  to  existing  objects  are  hand  ed  in  a  similar  fashion.  The  user 
interface  allows  the  user  to  choose  from  th(-  active  rules  applying  to  that  object 
to  invoke  the  changes.  Object  retrieval  can  be  accomplished  by  indicating  con¬ 
ditions  to  be  met  and  patterns  to  be  matched  within  the  fields  of  a  template. 
Object  deletion  is  merely  a  special  case  of  modification.  In  any  case,  once  the 
user  interface  constructs  a  fireable  event  that  satisfies  the  user,  it  presents  it 
to  the  object  manager  to  fire  it. 

In  order  to  integrate  the  user  interface  into  the  object-based  environment, 
the  user  is  modelled  as  a  special  "user  object"  that  is  capable  of  spontaneously 
communicating  with  other  objects  independent  of  its  predefined  behaviour. 
(The  alternative,  of  course,  is  to  design  a  user  object  behaviour  that  captures 
all  possible  events  that  users  might  ever  wish  to  participate  in.)  Not  every 
event  involving  users  requires  the  active  participation  of  a  logged-in  human 
being,  however.  A  predefined  behavioui’  enables  one  to  specify  certain 
automatic  behaviour.  Messages  sent  to  cv  user  objeet  can  be  automatically 
answered  in  some  cases  and  information  can  be  automatieally  reeeived  and 
stored.  Examples  of  automatic  behaviour  e.re  the  name  and  newcharge  rules  in 
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the  simple  zLser  object  described  below, 

user :  object  [ 

/*  instance  variables  */ 

charges  :  integer-, 

loginid,  pswd,  newpswd  :  string, 


/*  rules  */ 

alpha(id,pw)^  /*  rule  for  creating  ^Lser  objects  */ 
/*  only  ’superusers'  can  create  them  */ 

~  :  superuser-, 
id,  pw  :  string, 
loginid  <-  id; 
pswd  <-  pw, 
newpswd  <-  pw, 
charges  <-  0; 


name^  /*  return  loginid  to  anyone  */ 
~  :  object-, 

Kloginid) 


chgpswd(pw)^  /*  change  user's  password  -  */ 

/*  this  is  done  by  specifying  the  rule  */ 

/*  name  or  by  altering  the  newpswd  variable  */ 
A  :  accounting-, 
pw  :  string  -, 

I 

~  ;  user; 

~  /♦  can  only  talk  to  self  */ 

pw  5^  /*  non-null  string  */ 

newpswd  <-  pw; 

/*  newpswd  was  otherwise  ciltered  */ 
pswd  7^  newpswd; 

i 

pswd  <-  newpswd; 

/*  inform  accounting  object  of  change  */ 

A.  pswdupdate  ( newpswd) ; 

i 


newcharge(c)  \  /*  increment  charges  by  c  ♦/ 
~  :  accounting, 
c  ;  integer-, 

charges  <-  charges  +  c; 
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omegaj  /♦  only  superusers  can  destroy  */ 

~  :  supervsar] 

\ 

I 

In  other  cases,  events  initiated  by  other  objects  may  need  to  communicate 
with  the  user  directly,  A  request  for  a  non-existing  rule  in  the  case  of  a  user 
object  is  taken  to  mean  that  the  user  is  to  be  prompted  (rather  than  that  the 
request  be  considered  inappropriate).  In  addition,  a  customized  prompt  rule  in 
the  user  object  behaviour  may  be  fired  to  prompt  for  user  input. 

The  contents  of  the  user  object  may  be  modified  without  restriction  by  the 
user  himself  {ps^d),  or  by  other  objects  {charges)  through  the  rules  defined. 
(Values  that  must  not  be  altered  directly  by  users  can  be  associated  with  other 
objects.)  The  contents  may  be  part  of  a  "virtual  screen",  a  large  desk  top  of 
which  the  user  interface  can  present  windows  to  the  user  [BYTE61,  Swin74]. 
Separate  windows  would  be  available  for  the  user  to  manage  different  activities, 
such  as  defining  several  new  object  classes,  retrieving  cind  modifying  objects 
and  monitoring  events.  One  window  could  be  used,  for  exeimple,  to  monitor  the 
mailbox  for  receipt  of  fresh  mail,  and  another  window  might  be  a  clock  that 
displays  the  current  time.  Whenever  the  user  logs  in,  the  virtual  screen 
assumes  its  current  incarnation,  depending  on  what  events  were  fired  in  which 
the  user  object  was  a  participant  during  the  user's  absence. 

A  user  may  define  rules  that  apply  specifically  to  himself.  In  effect,  he 
becomes  a  sub-class  of  the  user  object  class.  With  these  rules  he  may  specify 
automatic  replies  to  prompts  or  he  may  customize  responses.  The  user  may 
also,  upon  request,  cause  certain  rules  to  become  active.  These  rules  could  be 
commands  the  user  wishes  to  execute  and  they  may  be  activated  by  altering  a 
variable  in  the  rule's  contents  or  by  specifying  the  rule  name  {chgpswd).  Tem¬ 
porary  rules  may  be  specified  w^hich  fire  once  and  then  disappear.  (This  is 
equivalent  to  modifying  the  class  to  include  the  rule,  invoking  the  rule,  and 
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then  modifying  the  class  to  delete  the  rule.)  Temporary  rules  are  useful  for 
defining  behaviour  that  occurs  only  once. 

6.  Conclusion 

Objects  are  a  natural  choice  for  describing  the  behaviour  of  office  informa¬ 
tion  systems.  The  object  environment  we  have  presented  is  capable  of  express¬ 
ing  many  of  the  components  of  such  systems.  Intelligent  forms  and  messages, 
workstations,  office  procedures  and  even  users  can  be  defined  as  object  classes. 
A  wide  collection  of  field  types  can  be  easily  expressed.  In  addition,  several  use¬ 
ful  frameworks  for  defining  office  procedures,  such  as  automata  and  Petri  nets, 
can  be  easily  simulated. 

Although  objects  do  not  explicitly  model  the  outside  world,  it  is  possible  to 
include  special  object  classes  that  talk  to  the  rest  of  the  universe.  Users  com¬ 
municate  with  objects  in  this  way,  One  benefit  of  this  approach  is  that  several 
different  user  interfaces  could  be  grafted  onto  the  same  system  without  having 
to  significantly  alter  the  object  manager. 

Objects  naturally  capture  the  three  most  important  aspects  of  office  infor¬ 
mation  systems:  information  management,  communication  and  partial  automa¬ 
tion.  Information  is  stored  in  object  instances  and  managed  by  rules,  commun¬ 
ication  between  objects  occur  when  events  are  fired,  and  automation  is 
achieved  through  rules  that  may  be  triggered  automatically.  Specialization  is 
used  for  defining  special  cases  of  object  classes,  or  for  defining  superclasses 
with  properties  that  their  specializations  have  in  common. 

We  are  building  a  prototype  OBS  at  the  University  of  Toronto.  We  are 
currently  in  the  design  stage  of  our  project,  and  we  expect  to  have  an  working 
version  of  the  system  within  one  year.  We  have  drawn  from  our  experience  in 
building  an  intelligent  message  management  system  [TRGH01].  Our  goal  is  to 
implement  a  programming  system  in  which  similar  and  more  powerful  systems 
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can  be  written  quickly  and  painlessly. 

Concurrently  with  the  development  of  this  system,  we  are  studying  notions 
of  correctness  in  office  procedures.  Poorly  defined  objects  may  unexpectedly 
exhibit  infinite  loops,  deadlock  and  other  undesirable  behaviour  [NiTs82].  Tech¬ 
niques  for  automatically  detecting  these  anomalies  and  for  presenting  users 
writh  a  view  of  global  behaviour  of  object  systems  are  being  developed. 


7.  An  object  grammar 

The  object  grammar  that  follows  is  only  a  skeleton.  There  are,  for  exam¬ 
ple,  no  special  keywords  like  "alpha"  or  "null",  no  built-in  arithmetic  expres¬ 
sions,  and  we  have  not  included  pattern-matching  in  our  conditions. 

<object>  <object-class>  [  ":"  <super-class>  ] 

I  <declaration>  ";"  J 
\  <rule>  J 

"I" 

<declaration>  ::=  <variable>  ^  ","  <variable>  I  <type> 

<rule>  <rule-name>  [  "("  [  <variable>  [  "."  <variable>  ]  ]  ")"  ] 

"I"  I  <statement>  ";"  ]  "j" 

[  "("  [  <variable>  \  "."  <variable>  \  ]  ")"  ] 

<stat.ement>  :;=  <declaration> 

<condition> 

,<send> 

<assignment> 

<sub-rule> 

<condition>  <variable>  <comparator>  <expression> 

<comparator>  :;=  "=" 

I  'V” 

i  "<" 

I  "<" 

1  ">" 

I  ">" 

<send>  ;•=  <acquaintdncc>  "."  <rule-namc> 

"("  [  <expression>  \  ",”  <expression>  i  ]  ")" 

<acquaintarice>  <v'dnc.ible> 

I  "<"  <object-class>  ">" 

<assignment>  <variable>  <expression> 

<expression>  ::=  <value> 

I  <variable> 

i  <function>  "("  [  <expression>  \  <expression>  ]  ]  ")" 

I  <send> 

<sub-rule>  'T' 

[  <statement>  ":"  ] 

\  "I"  ^  <statement>  \ 

M  )  n 
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<rule-name>  <identifier> 
<acquaintance>  <identifier> 
<type>  ::=  <iflentifier> 
<object-class>  <identifier> 
<super-class>  ::=  <Ldentifipr> 
<variable>  <ideiitifier> 
<function>  <identifier> 
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ABSTRACT 

Office  information  systems  provide  facilities  for  automatically  trigger¬ 
ing  procedures  when  certain  conditions  become  true  or  particular  events 
take  place  such  as  receipt  of  mail.  When  these  procedures  operate  con¬ 
currently  and  independently  in  a  common  environment,  the  overall 
behaviour  of  the  system  may  be  unexpected.  Firing  expressions  are  pro¬ 
posed  as  a  tool  for  describing  global  behaviour  and  for  detecting  unusual 
properties  of  the  system. 


1.  Introduction 


An  oj^ice  informatwn  system  is  a  computer  system  that  models  the  activi¬ 
ties  of  an  office.  One  would  expect  to  find  that  the  objects  defined  in  an  OIS 
parallel  the  real  objects  in  a  physical  office  such  as  desks  or  workstations, 
memos,  telephones,  calculators,  tables,  mail  trays  and  so  on.  An  OIS  presents  a 
uniform  medium  in  which  to  represent  the  objects  in  an  office  thus  permitting 
the  automation  or  partial  automation  of  routine  activities  and  providing  the 
advantage  of  increased  speed  of  communication. 

The  messages  passed  between  workstations  in  an  OIS  may  be  intelligent 
forms,  procedures,  or  any  appropriate  office  object.  Automation  in  such  sys¬ 
tems  is  enabled  by  permitting  events  to  trigger  other  events.  The  receipt  of  a 
certain  kind  of  message,  for  example,  may  trigger  a  procedure  which  automati¬ 
cally  reads  the  message  and  responds  to  it.  The  creation  or  modification  of  any 
object  may  also  trigger  an  event.  By  specifying  exactly  what  circumstances 
may  trigger  an  event  a  user  passes  the  responsibility  of  firing  it  to  the  system. 

The  firing  of  an  event  may  create  a  situation  in  which  some  other  event  is 
triggered.  All  such  new  events  are  then  also  fired.  This  process  continues  until 
the  system  ''stabilizes"  and  no  more  events  can  be  fired.  Since  an  event  may  be 
triggered  implicitly  rather  than  called  explicitly,  the  net  effect  of  firing  an 
event  may  be  far  from  obvious,  in  fact,  the  system  may  never  stabilize  if  events 
trigger  one  another  in  a  cycle  or  generate  new  events.  This  highly  parallel 
activity  can  be  difficult  to  understand  and  evaluate  unless  there  is  a  view  of  glo¬ 
bal  behaviour  available. 

The  task  of  describing  global  behaviour  is  a  general  one,  independent  of  the 
specific  OIS  application  being  studied.  A  model  is  needed  to  capture  this 
behaviour  without  being  bound  to  a  particular  class  of  applications.  We  cannot 
enumerate  and  anticipate  all  possible  applications.  We  approach  the  problem 
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at.  a  difTerent  level  by  providing  the  primitives  needed  to  define  such  systems. 
Any  results  obtained  from  our  analysis  of  global  behaviour  could  then  be 
embedded  in  a  system  based  upon  such  a  model. 

2.  Objects 

Objects  in  an  OIS  can  be  memos,  forms,  records,  messages  or  anything  else 
that  may  be  manipulated  by  a  user.  The  objects  that  are  of  greatest  interest 
here  are  thofie  that  are  fairly  regular  in  their  appearance  and  in  their  usage. 
Such  objects  may  be  automatically  processed  by  procedures  associated  with 
user  workstations  that  await  their  arrival,  creation  or  modification.  These  pro¬ 
cedures  may  look  for  objects  that  satisfy  certain  conditions,  or  they  may  coor¬ 
dinate  objects  that  belong  together.  Different  applications  and  different  imple¬ 
mentations  may  have  different  characteristics.  There  is  still  enough  regularity 
of  information  and  common  triggering  of  procedures.  It  is  possible  to  describe 
these  systems  with  a  model.  "Objects"  are  a  construct  that  can  be  used  to 
miodel  or  to  program  such  systems.  An  electronic  form  together  with  its 
characteristic  behaviour  could  be  coded  as  an  object,  as  could  messages,  pro¬ 
cedures,  mai’  trays  and  even  parts  of  the  user  interface.  An  "object"  [BYTE81, 
DeJoBO,  NiMT83]  is  an  entity  with  a  set  of  properties  and  a  behaviour  that 
describes  how  the  object  may  be  used  and  modified.  An  object  "knows"  its 
behaviour  and  is  responsible  for  it,  in  a  sense. 

An  object-based  system  enables  one  to  represent  objects  within  a  com¬ 
puter.  It  allov/s  users  to  define  classes  of  objects  with  contents  resembling 
database  relations  and  behaviours  resembling  bodies  of  associated  code.  A 
behaviour  consists  of  rules  for  the  creation,  transformation  and  destruction  of 
objects.  An  object’s  rules  may  be  triggered  implicitly  rather  than  having  to  be 
called  explicitly.  .4n  object  behaves  as  though  it  is  always  watching  for  a 
triggering  condition  to  become  true. 
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An  object-based  system  enforces  the  behaviour  by  detecting  conditions 
that  will  trigger  events.  This  is  the  task  of  managing  a  set  of  objects.  The  state 
of  the  world  is  characterized  by  the  states  of  the  objects  in  it.  A  particular 
object  may  take  on  a  number  of  vedues  in  its  lifetime,  but  the  changes  happen 
in  a  restricted  way. 

Objects  interact  by  "doing  things"  to  each  other  that  "make  sense".  Cer¬ 
tain  actions  may  only  make  sense  for  objects  in  a  particular  state.  One  can 
only  fix  a  chair,  for  example,  if  it  is  in  a  "broken"  state.  When  two  or  more 
objects  interact,  something  "happens",  that  is,  the  properties  of  some  of  the 
objects  may  change. 

Objects  have  both  contents  and  behaviour.  Contents  consist  of  instance 
variables  which  distinguish  objects  in  the  same  class  somewhat  like  attributes 
distinguish  tuples  in  the  same  relation.  They  may  also  be  compared  to  the 
static  variables  of  a  module.  Throughout  an  object’s  lifetime  these  contents 
may  change.  The  values  of  all  the  objects  in  the  system  determine  the  state  of 
the  system.  Value  changes  may  occur  because  certain  conditions  become  true, 
or  they  may  take  place  as  a  consequence  of  one  object  interacting  with  another 
object.  An  object's  behaviour  is  a  set  of  rvles  describing  the  situations  under 
which  these  value  changes  may  normally  occur. 

Objects'  contents  are  simply  a  set  of  variables,  each  of  which  ranges  over 
some  set  of  values.  They  may  be  stored  in  data  structures  such  as  those  pro¬ 
vided  by  a  high  level  programming  language  like  Pascal  or  C.  A  rule  is  a  named 
body  of  code.  Rules  specify  trigger  conditions,  communicate  with  other  objects 
and  modify  contents. 

The  firing  of  an  object’s  rule  is  the  execution  of  its  statements.  A  rule  is 
fireable  if  its  statements  may  be  successfully  executed.  A  rule  may  only  fire  if 
all  the  conditions  in  the  rule  are  guaranteed  to  hold  upon  firing.  This  elim- 
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inates  the  need  for  "postconditions"  and  the  idea  of  "success"  or  "failure"  of  a 

rule.  A  rule  is  active  if  the  conditions  that  refer  to  its  instance  variables  alone 
are  true. 

If  for  any  reason  a  rule  is  not  fireable,  then  none  of  its  statements  are  exe¬ 
cuted. 

An  event  can  be  fired  whenever  there  exists  a  collection  of  objects  that 
wish  to  communicate  through  rules  whose  trigger  conditions  are  all  true.  An 
event  is  fired  by  firing  all  the  rules  in  that  event.  We  assume  that  every  fireable 
event  eventually  either  (l)  get  fired  or  (2)  get  deactivated  by  the  firing  of  some 
other  event.  In  [NiMT83]  we  give  a  more  thorough  discussion  of  objects  and  out¬ 
line  an  implementation.  In  the  appendix  we  give  an  example  of  an  object. 

3.  Correctness  and  globed  behaviour 

Objects  as  they  are  described  above  suggest  a  number  of  questions.  First 
of  all,  there  is  nothing  in  an  object’s  behaviour  that  tells  us  what  an  event  looks 
like.  We  only  see  an  object’s  immediate  acquaintances,  not  the  entire  set  of 
participants  of  am  event.  We  may  also  not  be  able  to  tell  from  a  rule's  reference 
to  acquaintances  exactly  what  classes  of  objects  are  matched,  or  precisely  what 
rules  within  those  objects  will  be  matched.  This  is  analogous  to  not  knowing 
what  procedures  are  ultimately  going  to  make  use  of  a  library  of  functions. 

Furthermore,  the  overall  behaviour  of  the  system  we  have  defined  may  not 
correspond  to  what  we  had  in  mind.  This  is  analogous  to  the  problem  of  debug¬ 
ging  a  program.  The  problem  is  more  difficult  here  because  we  are  not  defining 
programs  to  be  run  at  a  single  instant  in  time,  but  rather  a  set  of  cooperating 
programs  that  have  an  extended  lifetime.  Tlie  interactions  between  existing 
objects  and  newly-defined  ones  may  be  difficult  to  determine  and  comprehend 
in  an  OIS  of  any  complexity. 
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In  a  running  system,  it  may  be  desirable  to  monitor  the  progress  of  the 
objects  currently  defined.  Suspicious  behaviour  may  be  detected  by  identifying 
those  objects  which  are  not  proceeding  at  an  expected  rate, 

Some  automatic  analysis  is  required  that  will  (l)  provide  users  with  a  view 
of  global  beha\lour  and  (2)  point  out  any  behaviour  that  is  unusual.  There  can 
be  no  a  priori  bad  behaviour  because  an  OIS  is  necessarily  not  a  closed  system. 
What  may  look  like  deadlock  may  in  fact  be  a  way  of  preventing  certain  events 
from  taking  place  except  under  very  unusual  circumstances. 

We  assume  that  all  objects  are  meant  to  be  created,  go  through  a  series  of 
transformations,  and  then  peacefully  die.  We  may  be  able  to  detect  the  possi¬ 
bility  of  objects  being  frustrated  in  their  attempts  to  fulfill  this  goal. 

The  creation  of  an  object  is  accomplished  by  firing  an  initial  rule  (called 
alpha)  which  brings  it  from  the  initial  stale  (or  alpha  state)  to  a  state  in  which 
its  contents  assume  some  value.  An  object  eventually  is  destroyed  when  o.  final 
rule  (called  om.ega)  is  fired,  bringing  it  to  its  ftnai  state  (or  omega  state),  which 
causes  the  object  to  be  archived,  printed,  forgotten,  or  otherwise  leave  the  set 
of  active  objects.  An  object  is  stuck  if  it  is  prevented  from  reaching  a  final 
state.  An  object  may  get  stuck 

(1)  if  it  reaches  a  state  in  which  no  rule  is  active 

(2)  if  it  cycles  infinitely  through  the  same  set  of  states, 
never  reaching  a  final  state 

(3)  if  it  reaches  a  state  in  which  it  waits  forever  for  an  acquaintance  to 
reach  a  certain  state  because  that  acquaintance  is  stuck  or  because  that  state 
is  unattainable  or  is  simply  never  reached. 

An  analysis  of  of  objects'  behaviours  can  also  tell  us 
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(4)  whal  states  are  unattaiaable  and 

(5)  whether  there  are  rules  that  can  never  fire  because  the  object  can 
never  reach  a  state  in  which  those  rules  are  active. 

Our  task  is  to  abstract  our  object  model  to  a  simpler  model  that  captures 
state  changes  and  firing  sequences.  This  abstraction  must  then  be  interpreted 
to  evaluate  the  global  behaviour  of  an  OIS. 

4.  Object  states 

We  are  concerned  primarily  with  the  possible  life  histories  of  objects,  that 
is,  the  sequence  of  states  a  objects  reaches  and  the  sequence  of  rules  fired  from 
state  to  state.  A  state  is  some  set  of  values  that  an  object  may  (or  may  not) 
reach.  If  states  are  blocks  in  some  partitioning  of  the  range  of  an  object’s  con¬ 
tents,  then  we  need  some  criteria  for  establishing  the  partition.  Since  rules  are 
the  only  means  by  which  objects  may  change  state,  an  object’s  state  must  be 
related  to  whether  a  rule  is  fireable. 

The  simplest  possible  state  space  would  consist  of  a  single  state.  Since  we 
are  interested  in  life  histories,  we  would  naturally  add  the  initial  and  final 
states.  One  might  add  one  state  per  rule  -  an  object  being  in  a  particular  state 
if  that  rule  is  active,  but  several  rules  may  be  active  at  any  one  time,  and  an 
object  may  be  in  only  one  state  at  a  time. 

The  first  reasonable  state  space  might  be  to  consider  2^  states  where  there 
are  n  rules,  since  each  rule  may  be  either  active  or  inactive.  Some  states 
would,  however,  correspond  to  no  objects  since  we  may  expect  some  rules  to  be 
mutually  exclusive.  In  the  inv  object  outlined  in  the  appendix,  excluding  the 
alpha  and  omega  rules,  either  all  rules  are  active  or  all  rules  are  inactive. 

A  more  reasonable  approach  would  be  to  consider  all  the  conditions  placed 
on  the  instance  variables  of  an  object.  M  object  is  in  a  given  state  if  it  satisfies 
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that  set  of  conditions.  The  conditions  in  the  behaviour  of  the  inv  object  are 
total=0  in  the  omega  rule,  and  totatyO  in  the  lose  rule  (in  the  first  alternative 
of  the  sub-rule,  totat>n  where  n>n).  We  have,  then  the  states  a,  the  initial 
state,  Iq  (where  total=0),  (where  totcd>Q),  t .  (where  total<0),  and  cj,  the  final 
state. 

The  significance  of  states  is  that  they  capture  what  rules  may  be  active  for 
an  object.  Rules  map  objects  from  states  to  states  and  consequently  cause 
different  rules  to  become  active.  An  object’s  state  graph  is  a  digraph  with  nodes 
representing  states  and  arcs  representing  state  transitions.  For  every  arc 
there  must  be  at  least  one  rule  active  in  the  state  at  the  arc's  tail  which,  when 
fired,  may  cause  the  object  to  reach  the  arc’s  head.  A  state  graph  may  be 
simplified  by  combining  states.  For  example,  a  collection  of  states  with  identi¬ 
cal  out-going  arcs  may  be  combined  since  they  share  the  same  next-state  set. 

The  dicomponents  of  the  state  graph  are  the  sets  of  mutually  reachable 
states.  Since  these  states  are  mutually  reachable,  an  object  may  loop  infinitely 
through  the  states  in  a  dicomponent  unless  the  dicomponent  contains  only  a 
single  state  and  there  is  no  loop  from  that  state  to  itself.  The  dicomponents  of 
the  inv  state  graph  are  \al,  \tQ,t and  Any  dicomponent  without  out¬ 
going  arcs  is  terminal.  If  this  dicornponent  is  not  the  omega  state,  then  it  is  a 
dead  dicomponent  since  it  can  never  reach  the  omega  state.  Any  dicomponent 
without  incoming  arcs  is  unattaina')le,  except  the  alpha  state.  {\t_l  is  an  unat¬ 
tainable  dicomponent).  Any  dicomponent  whose  only  incoming  arcs  are  from 
an  unattainable  dicomponent  is  also  unattainable.  Any  dicomponent  whose 
only  outgoing  arcs  are  to  a  dead  dicomponent  is  also  dead.  Any  state  in  a  dead 
dicornponent  is  a  dead  state.  All  other  dicomponents  are  Live. 

A  rule  is  composed  of  statements.  The  condition  for  the  rule  is  the  conjuc- 
tion  of  all  its  constituent  conditions.  A  sub-rule  may  contain  alternatives.  The 
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A  state  graph  for  inv  objects 


condition  for  the  sub-rule  (a  statement)  is  the  disjunction  of  its  constituents. 


eg. 

\  X  >  1; 

X  ^  5 

I  y  >  0;  y  <  1  1  y  > 
j  z  <  0  1  z  >  lOji 

i 


The  condition  for  this  rule  (which  contains  no  executable  statements)  is 
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(((2:>1)a(x<5)  a(|/>0)  a(7/  <1)a(z  <0))\/ 

((a:>l)A(x<5)  A(?/>0)A(y  <1)a(2  >lO))v 
((x>1)a(x  <5)A(y>2)A(z  <0))\/ 

((x>1)a(j;  <b)A(y  >2)a(z  >10))). 

We  must  take  a  cross  product  of  conditions  in  sub-rules  to  obtain  our  rule  con¬ 
dition  in  disjunctive  normal  form.  If  there  are  no  other  conditions  in  any  other 
rule,  then  each  of  these  conditions  corresponds  to  a  state.  Otherwise  they  each 
correspond  to  several  states.  The  condition  represents  a  collection  of  states 
vrliich  is  the  domain  of  the  rule. 

In  this  case  our  conditions  would  produce  the  following  state  space: 

1(1.5). (-“.l)u[5-)ix  K0.l).(2.~),(-oo.0)u[l.2]ix  H-“.0).(l0-).[0.10]j 

The  rule  above  would  be  active  in  four  of  the  eighteen  states.  Here  we  end  up 
with  too  fine  a  partition  of  objects’  states  by  considering  all  combinations  of  all 
conditions.  It  would  therefore  be  desirable  to  combine  certain  states  if  they  are 
in  some  sense  equivalent.  Non-empty  intersections  of  rule  domains  and  their 
complements  might  determine  a  better  state  space.  In  this  case  the  four  states 
would  be  combined  into  one  state  and  the  remaining  fourteen  would  be  com¬ 
bined  to  produce  another  state. 

5.  Formal  abstraction 

An  object  class  Chas  a  set  of  variables  V{C),  a  domain  Dc{y)  for  each  vari¬ 
able  i;gF((7),  and  a  set  of  rules  R{C).  The  instances  of  C  are  the  mappings 
I{C)=lfi\^{v)^Dc{v)yv^V{C)l.  The  rules  R(C)  are  a  relation  over  the  instances 
of  C  (i.e.  a  rule  need  neither  be  well-defined  nor  totally  defined)  We  model, 
therefore,  whether  a  rule  is  active  and  what  states  may  result  from  firing  it.  but 
we  do  not  (yet)  model  those  firing  conditions  that  depend  on  outside  informa¬ 
tion  (i.G.  the  state  of  an  acquaintance). 
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The  precondiMon  for  firing  a  rule  rcR{C)  is  that  the  instance  fu,£l{C) 
belong  to  the  domain  of  the  rule  p(r)  =  |yL(e/(C)  jr  is  defined^. 

Clas.i  q  is  a  specialization  of  Cj  if  K(C’ ):j K(Cj).  We  write  C;>Cy.  The  base 
object  class  is  Cq  where  K(Co)=0  and  R{Cq)~(P.  We  have  therefore  Ci>Co^.  Spe¬ 
cialization  is  a  partial  order  on  object  classes. 

A  state  space  ^(r)  may  be  defined  as  follows: 

5(C)  =  ^sc/(r;)|s=(np(r))n(n  nC)\p{r))i^ip.XQR{C)l 

reX  rgX 

This  state  space  would  have  at  most  states  where  n  =]/?((?)  ] ,  since  all  combi¬ 
nations  of  active  rules  are  considered.  In  fact,  however,  mciny  rules  will  have 
no  associated  conditions,  such  as  the  total  rule,  for  which p(fofaZ)=/(C).  Other 
rules  may  be  mutually  exclusive.  Many  of  the  states  so  generated  will  therefore 
be  empty  and  so  will  not  contribute  to  the  state  space  S{C). 

A  firi/ng  p.xpression  [NiTsBS,  Shaw78]  is  a  regular  expression  representing 
the  set  of  all  possible  rule  firing  sequences  and  state  changes  for  an  object. 
Since  ob  ects  generally  require  acquaintances  for  their  rules  to  fire,  one  must 
examine  the  firing  expression  of  possible  acquaintances  to  decide  whether  they 
may  ever  reach  a  state  in  which  the  matching  rule  is  active.  An  iterative  algo¬ 
rithm  may  be  used  to  sort  through  all  firing  expressions  to  decide  if  the  rules  in 
the  sequences  may  actually  become  fireable  by  finding  a  matching  rule  in 
another  nring  sequence. 

The  firing  expression  for  an  object  class  corresponds  to  the  set  of  strings 
accepted  bv  the  aulomatoi.  A  =  <S,R. 6, a.c>»  with  states  S,  alphabet  R,  initial 
state  a.  Inal  state  and  state  change  function  5  where  .r)os' 

If  the  firing  expression  is  to  include  state  changes  as  well  as  rule  firings,  then 
the  alphabet  is  A’x5,  a.nds  ed{s  .{r  .s'))<^s'r)r{I)^(p. 

The  Tring  expression  including  state  changes  for  the  inv  object  is 
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tx  iiiphaitQ-ht  :^  {(grdn■\■los2  ■h'jyrice  =)t  lose  Iq) 

({lose  +priy:e  =)iQ-^gai7i  t  +  [{gain + lose  -^rpHce  =)t.  lose  Iq)*  omega,  q. 

(Since  the  item,  total  andpnce  ralnc  do  not  cause  any  state  changes,  they  have 

been  left  out.)  If  state  changes  are  ignored,  this  expression  simplifies  to 

alphti{gmn\ga,i7i  -i-pric^  -)*lose  ¥lose  +//n'ce  -)* omega. 

Firing  expressions  may  be  nsei  to  generate  po-w  expressions.  If  certain 
kinds  of  objects  have  ar.  otaner  attribute  indicating  who  may  modify  it  at  any 
given  time,  then  ccirtain  states  will  correspond  to  ownership  by  a  given  worksta¬ 
tion.  The  firing  expressions  may  be  used  to  determine  what  sequences  of  works¬ 
tations  may  own  the  object,  i.e.  how  the  object  pows  through  the  network. 

Non-determirlsm  may  enter  the  model  in  3  different  ways:  (l)  The  state 
space  may  not  be  fine  enough  to  capture  all  state  transitions  accurately  (an 
increment,  of  a  variable  may  or  may  not  cause  a  state  change)  (2)  Incoming 
data  from  acquaintances  or  functior  s  cannot  be  predicted  (3)  A  genuinely  non- 
deterministic  sou"ca  (a  random  r  uirber  generator  or  user  input)  may  be  used. 

If  rules  require  no  acquaintances,  if  conditions  are  simple  comparisons  of 
variables  lo  constants  and  if  firing  a  rule  wll  only  set  variables  to  constants, 
then  firing  expressions  are  completely  detei  ministic.  If  more  general  actions 
are  permitted  and  variables  may  be  set  to  values  returned  by  functions,  then 
firing  expressions  become  regular  expressions,  and  non-determinism  is  intro¬ 
duced. 

6.  Conclt^ions 

OlSs  can  exhibit  quite  complicated  behaviour  when  automatic  procedures 
are  introduced.  Global  office  activity  that  maneges  objects,  e.g.  messages,  can 
be  hard  to  understand  when  independent  local  procedures  vie  for  control. 
Techniques  for  d.rsc ribmg  and  aiuilysing  global  behaviour  are  needed  as  a 
means  to  determining  whether  these  systems  behave  "correctly".  Some  kinds 
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of  unusua  beha'.  iour  can  be  identified  Firing  expressions  are  suggested  as  an 
approach  to  studying  global  behcviour  and  detecting  peculiarities  that  are  of 
interest  to  users  and  programmers. 

7.  /^pend-x 

A  specification  for  an  objecv,  class  inv  follows.  Instances  are  inventory 
objects  used  to  keep  track  the  number  of  items  in  stock.  We  use  the  notation 
outlined  in  [Ni'TVIdS]. 

The  contents  of  the  inv  object  are  the  variables  item,  total,  price,  auth  and 
date.  Its  behaviour  consists  of  the  rules  alpha,  item,  total,  price,  price  =  ,  gain, 
lose  and  omega.  The  inv  object  is  a  specialization  of  the  null  object  class 
object,  wh;ch  has  no  contents  or  behaviour.  Every  object  must  have  an  alpha 
rule  and  an  omega  rule  for  creatir.g  and  destroying  it. 

The  conditions  appearing  in  e.  rule  may  refer  to  the  object’s  contents,  or  to 
any  value  sent  by  an  acquaintance,  an  object  interacting  with  it.  The  acquain¬ 
tance  variables  n  the  above  rules  are  ~  and  B.  (~  is  the  object  invoking  the 
rule,  if  th-re  be  one.)  The  rube  ma}  also  produce  values  to  be  sent  to  acquain¬ 
tances  or  to  be  used  in  modifying  the  object’s  contents.  The  alpha  rule  above 
obtains  the  name  of  its  one  acquaintance  for  setting  one  variable,  and  it  gets 
the  current  time  by  calling  aglobal.ly  defined  time  function. 

Rules  may  be  named  like  thu  procedures  of  a  module  or  an  abstract  data 
type,  but  thoy  may  also  be  triggered  without  having  to  be  explicitly  called  by 
another  object.  Conside.*"  t  he  following  rule  added  to  the  behaviour  of  inv\ 

panici 

M  :  manager; 

total  =  0; 

auth  =  M  name(); 

M  panic(item); 

i 

This  rule  would  be^  triggered  whenever  the  total  field  hit  zero.  There  is  no 
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acc;uaintance  for  this  rule  (and  hence  no  need  to  name  it).  This  would  be  useful 
for  separating  triggering  conditions  from  the  events  that  cause  them.  There 
are,  for  example,  two  distinct  ways  in  which  total  could  be  set  to  zero.  There  is 
no  need  to  check  this  condition  at  those  points.  Note,  however,  that  the  panic 
rule  can  only  be  deactivated  by  the  gain  or  omega  rules,  and  so  would  fire 
repeatedly  until  one  of  these  other  rules  fired. 

inv :  object  ^ 

/*  instance  variables  */ 
item,  total,  price  :  integer, 
auth  ;  string, 
date  :  time\ 


/*  rules  */ 

alpha(i,t,p)f  /*  rule  for  creating  inv  objects  */ 
only  managers  can  create  them  */ 

~  :  manager, 
i,  t,  p  :  integer-, 

/*  conditions  on  the  input  */ 
i  >  0; 
t>  0; 

p^  0; 

item  ^  i; 
total  <-  t; 
price  p; 

/*  get  the  creator’s  name  by  invoking  his  name  rule  */ 
auth  <-  ~.name(); 
date  <-  time(); 


item| 

/*  return  item  to  anyone  who  v/ants  it  */ 
~  ;  object, 

{(item) 

total[ 

/*  return  total  to  anyone  who  wants  it  */ 
~  :  object-, 

{(total) 

price! 

/*  return  price  to  anyone  w  ho  wants  it  ’*'/ 
~  :  object, 

{(price) 
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pricc=(p)f 

/'*'  only  managers  can  change  the  price  field  * / 
~  :  raanagar, 
p  :  integer, 
p>  0; 

price  <-  p; 
auth  ~.name(). 
date  ♦-  time(); 


gam(n)l 

/*  increment  the  total  number  of  items  */ 
~  :  object, 
n  :  integer, 
n  >  0; 

total  *-  total  +  n; 

1 


lose(n)| 

/*  fill  an  order,  return  the  amount  filled  */ 

~  :  object] 
n  :  integer] 
n  >  0; 

total  >  n; 

/*  the  usual  case  * / 
k  <  n; 

total  <-  total  -  n: 

I  /*  alternatively;  */ 

/*  can’t  fill  order;  create  a  backorder  ♦/ 
B  ;  backorder] 
k  ♦-  total; 

B.alpha(~,item.n-k); 
total  ^  0; 

i 

/*  return  the  size  of  the  order  filled  */ 

Kk) 


omegal 

/*  only  managers  can  destroying  objects  */ 
~  ;  manager, 

/*  can’t  have  any  leftover  stock  */ 
total  =  0; 

i 
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Abstract 


In  Office  Information  Systems,  the  primary  focus  has  been  to  integrate  facilities  for 
the  communication  and  management  of  information.  However,  the  human  factors  as¬ 
pects  of  the  design  of  office  systems  are  equally  important  considerations  if  such 
office  systems  are  to  gain  widespread  acceptance  and  use.  The  application  of 
design  techniques  from  Human  Factors  can  help  enhance  the  usability  of  an  office 
system.  In  this  paper,  we  describe  the  user  interface  of  an  office  system  developed 
by  adapting  such  design  techniques. 
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1.  Introduction 


A  major  emphasis  in  Office  Information  Systems  Is  to  develop  techniques  to 
automate  information  handling  and  processing  in  an  office  in  order  to  deal  with  the 
rapid  growth  of  the  organization  and  the  increasing  demand  for  services  [TsLo80]. 
To  meet  this  objective,  there  is  a  need  to  integrate  facilities  such  as  electronic  mail, 
file  and  retrieval,  and  text  processing  into  a  common  environment  to  effectively 
access  the  information  and  to  control  and  coordinate  the  information  flow  [DeJo80, 
EIBe82,  SIKV82,  Tsic80,  Will83,  Zloo76]. 

The  human  factors  aspects  of  the  design  of  such  office  systems  eire  also  very 
impKDrtant  since  these  systems  should  be  easy  to  learn  and  easy  and  more  efficient 
to  operate.  These  issues  are  extremely  Important  because  of  the  broad  range  of 
user  types  (i.e.,  non-computer  professionals  to  office  clerks)  and  because  the  poten¬ 
tial  impact  of  an  office  system  on  its  user  community  is  large  [Loch81  ]. 

With  the  falling  cost  of  hardware  and  the  emergence  of  powerful  graphics- 
oriented  personal  workstations,  it  is  possible  to  design  office  systems  that  are  highly 
usabfe.  This  can  be  accomplished  by  exploiting  the  flexibility  afforded  by  graphics 
for  representation,  communication  and  interaction  as  in  the  Star  [SIK\/82]  and  Lisa 
[WIII83].  Unfortunately,  the  Star  and  Lisa  do  not  provide  functional  capabilities,  such 
as  those  described  in  [Tsic81],  that  allow  the  system  to  take  a  more  active  role  in 
the  communication  and  management  of  information. 

In  this  paper,  we  will  outline  the  design  of  a  new  user  interface  for  an  existing 
office  system  that  provides  the  functionality  described  in  [Tsic81].  Specifically,  we 
will  describe  how  a  number  of  features  that  we  have  incorporated  in  the  new  inter¬ 
face  enhances  the  usability  of  this  system.  We  believe  that  the  marriage  of  tech¬ 
niques  developed  In  Human  Factors  and  Office  Information  Systems  can  bo  extremely 
effective  In  achieving  the  twin  objectives  of  functionality  and  usability. 
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2.  Message  Management  Systems 

A  Message  Managment  System  (MMS)  is  an  information  system  which  is  able  to 
manage  both  structured  data  (e.g.,  records)  and  unstructured  data  (e.g.,  picture, 
voice).  It  has  the  data  communication  capabilities  of  a  message  system,  as  well  as 
the  data  management  capabilities  of  a  data  base  meinagement  system  [Tsic81  ]. 

The  basic  unit  of  communication  or  information  exchange  in  the  system  is  a  mes¬ 
sage.  A  message  is  an  Instance  of  a  message  type.  Each  message  is  composed  of  a 
form-like  message  template  and  a  set  of  i/alues.  The  message  template  imposes 

structure  and  meaning  on  its  contents  (i.e..  Its  values).  The  system^  of  interest  here 
(henceforth  referred  to  as  the  MMS)  is  partitioned  into  a  number  of  logical  units 
called  workstations.  Each  v>/orkstation  contains  an  information  repository  (MRS  rela¬ 
tional  data  base  [K.orn79])  that  stores  all  information  associated  with  the  worksta¬ 
tion.  Each  message  is  stored  as  an  entry  in  a  relation  for  the  defined  message  type. 

The  tools  provided  by  the  MMS  allow  the  user  to  query  and  edit  message 
instances,  service  facilities,  and  the  workstation's  message  repositories.  Editing 
operations  such  as  copying,  printing,  filing,  mailing,  retrieving,  displaying,  and  text 
processing  are  provided.  Querying  operations  allow  the  user  to  inquire  about  Informa¬ 
tion  stored  in  the  system  such  as  tracing,  locating,  and  finding  out  the  contents  of 
messages  and  other  objects  in  the  system. 

3.  Overviev7  of  the  User  Interface 

The  MMS  display  screen  is  diviaed  into  a  number  of  fixed  size  static  windows 
(Figure  1).  The  SYSTEM  window  displays  all  error  messages  and  warnings.  The  two 
primary  wor'<.ing  windows,  where  all  the  MMS  operations  are  initiated,  are  called 
DOCUMENT  and  WORKSTATION.  The  DOCUMENT  window  displays  a  faithful  represen¬ 
tation  of  how  the  document  will  look  when  printed.  This  is  where  all  text  processing 
related  operations  are  performed.  The  WORKSTATION  window  Is  where  ail  operations 

"^The  system  Is  described  fully  in  [TGRN82]. 
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relating  to  the  workstation  are  performed.  In  both  these  windows,  the  selection  tar¬ 
get  icon  ('x'  located  at  the  bottom  left  hand  corner  of  the  window)  can  be  used  to 
select  the  window.  In  certain  operations,  the  user  must  designate  which  working 
area  the  command  is  to  be  applied  to,  by  selecting  the  appropriate  window.  The  OUT¬ 
LINE  window  displays  a  skeleton,  a  complete  but  condensed  outline,  of  the  displayed 
document.  The  highlighted  portion  of  the  skeleton  is  the  portion  of  the  document  that 
is  visible  in  the  DOCUMENT  window.  As  well,  the  skeleton  can  be  used  to  bring  into 
view  another  portion  of  the  document  by  selecting  the  skeleton  item  that  identifies 
the  portion  of  the  document  that  the  user  wants  to  view.  The  LISTING  window 
displays  the  listings  produced  by  the  HELP  and  QUERY  commands.  A  scrolling  mechan¬ 
ism  in  the  DOCUMENT,  OUTLINE,  and  LISTING  windows  allows  the  user  to  scroll  the 
contents  of  these  windows  up,  down,  left  or  right  The  left  edge  of  the  window  con¬ 
tains  the  up  and  down  scrolling  regions  while  the  bottom  edge  contains  the  left  and 
tight  scrolling  regions.  A  scroll  operation  is  performed  by  moving  the  cursor  to  the 
scrolling  region  designating  the  scroll  direction  and  selecting  it  (Figure  1). 

Workstation  operations  pertain  to  the  management  of  the  workstation's  objects 
and  their  contents.  The  generic  ol^jects  of  the  MMS,  represented  as  icons  [Lodd83] 
(Figure  1),  are  messages,  message  folders,  envelopes,  stations,  filing  cabinets, 
printers,  mall  trays,  and  garbage  cans.  As  described  in  [Lee  83],  these  objects  are 
grouped  by  functionality  (I.e.,  data  and  server  objects)  and  subclass  (i.e.,  class,  type, 
and  instance).  The  data  bearing  objects  of  the  MMS  are  characterized  as  primitive  or 
aggregate  (objects  that  may  contain  primitive  data  objects).  The  server  objects  are 
characterized  as  those  MMS  objects  that  serve  as  repositories  for  the  data  objects 
(i.e.,  storage)  or  perform  specific  functions  (i.e.,  facility).  Text  processing  operations 
(I.e.,  editing  and  formatting)  permit  the  user  to  create  and  modify  the  displayed  mes¬ 
sage  or  system  form. 

A  small  set  of  universal  commands  are  defined  in  the  MMS.  These  commands 
apply  to  any  object  in  the  MMS.  They  are: 
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COPY 

HELP 

MARK 

MOVE 

UNDO 

COPY  Three  actions  are  possible,  depending  on  the  context  in  which  COPY  is 
used: 

o  A  new  object  is  created  by  copying  an  existing  object,  as  in  the  Star, 
o  An  existing  object  may  be  duplicated, 
o  A  hardcopy  of  an  object  may  be  produced. 

HELP  Three  different  forms  of  help  are  provided,  depending  on  the  object 
chosen: 

o  on-line  documentation 
o  help-by-example 

o  list  a  set  of  operations  just  completed 

MARK  This  command  allows  the  user  to  set  checkpoints  before  operations  (i.e., 
text  processing  or  workstation  type  of  operations)  which  the  third  form  of 
HELP  and  UNDO  operations  refer  to.  Operations  are  listed  from  or  undone 
back  to  the  most  recent  checkpoint  for  the  given  type  of  operation. 

MOVE  The  user  may  re-arrange  the  position  of  the  Icons  in  the  WORKSTATION 
window  or  text  in  the  document  in  the  DOCUMENT  window.  As  well,  the 
user  may  initiate  a  workstation  operation  by  moving  a  data  icon  into  a 
server  icon.  Tl'iis  will  result  In  the  storage  of  the  data  object  in  the 
selected  storage  object  or  cause  the  specific  function  of  the  selected 
facility  object  to  be  performed. 

UNDO  This  command  allows  the  user  to  undo  the  effects  of  a  set  of  operations 
just  completed.  A  second  UNDO  will  redo  the  operations. 

Aside  from  the  universal  commands,  two  additional  commands,  QUERY  and 

RETRIEVE,  have  been  defined  to  augment  the  workstation  operations 
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QUERY  This  command  is  used  to  trace,  locate,  or  retrieve  an  image  of  a  group  of 
messages  or  obtain  a  list  of  the  Instances  or  contents  of  the  selected 
MMS  generic  object. 

RETRIEVE  This  command  enables  the  ^y!MS  user  to  retrieve  data  objects  from  server 
objects. 

Similarly  In  text-processing  operations,  some  specific  edit-format  commands  (Table 
1)  have  been  defined.  For  those  format  attributes  that  cannot  be  altered  by  these 
commands,  the  MMS  provides  a  general  format  command  (i.e.,  FORMAT  -  Figure  2),  like 
the  took  command  in  Bravo  [Lamp78].  As  well,  a  FIND  command  is  provided  for  text 
searching  and  replacements  (Figure  4).  This  facility  allows  the  user  to  perform  global 
searching  and  substitutions  over  the  entire  document  or  portions  of  the  document. 

The  user  initiates  an  operation,  by  directly  manipulating  [Shne83]  the  icons, 
text,  selection  targets,  or  skeleton  items  using  the  universal  commands  in  a  manner 
similar  to  the  Star  and  Lisa.  The  semantics  of  each  workstation  operation  is  deter¬ 
mined  by  the  command  and  the  type  of  objects  that  make  up  the  operation^. 

The  format  of  the  MMS  command  language  is: 

<scope>  <command>  <target/options> 

The  first  operand  is  the  domain  of  the  command.  The  second  operand  is  either: 

(1)  the  target  from/to  which  the  domain  object  is  copied,  moved,  queried,  or 
retrieved,  or 

(2)  the  options  of  the  command  (e.g.,  which  font  for  a  change  of  font  command). 

In  some  commands,  the  second  operand  is  null  if  it  is  not  required  for  the  operation. 

A  system  form  Is  a  form-like  template  that  can  be  used  to  identify  some 
operands  of  a  command.  For  example,  for  a  retrieval  operation,  message  objects  are 

2 

The  syntax  and  semantics  of  all  the  MMS  workstation  operations  are  described  in  detail  In  [Lee 

83  j. 
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Identified  by  giving  a  set  of  specifications  (full  or  partial)  that  describe  them.  The 
specifications  are  entered,  using  a  by-example  approach  [Zloo76],  into  a  template 
(Figure  3).  This  template  is  identical  to  the  message  template.  The  specifications 
act  as  a  filter  that  restricts  the  domain  of  messages.  A  system  form  may  also  be  a 
list  of  options  (appearing  as  menu  items  or  fill-in  the  blank  entries)  that  the  user 
selects  or  fills  (Figure  2).  Other  operands  of  a  command  may  be  identified  by  select¬ 
ing  menu  items,  appropriate  icons,  skeleton  items,  or  selection  targets. 

All  MMS  commands  can  be  selected  from  a  menu.  However,  some  text  process¬ 
ing  commands  may  also  be  identified  by  sketching  a  character.  These  characters, 
similar  to  the  proofreading  symbols^,  have  been  defined  for  frequently  used  text  pro¬ 
cessing  commands. 

User  input  is  supplied  via  a  keyboard  for  text  entry  and  a  puck  and  tablet  for 
selection  and  graphical  input.  Two  buttons  are  sufficient  in  the  MMS;  one  button  for 
selection  and  another  for  expending  a  selection  (e.g.,  selecting  a  sequence  of 
words).  To  ABORT  command  specification,  the  user  simply  presses  both  buttons  at 
once. 

4.  Discussion 

The  MMS  user  interface  exploits  the  graphic  capabilities  of  the  bit-map  display 
and  the  direct  manipulation  capabilities  of  the  puck  and  tablet  to  provide  an  effec¬ 
tive  and  flexible  means  of  visual  communication  and  interaction  between  the  user  and 
the  system.  A  graphical  user  interface  and  direct  manipulation  allow  the  user  to 
recognize  and  point  instead  of  remember  and  type  [Lodd83].  The  display  is  the 
medium  through  which  objects,  actions,  and  effects  of  actions  are  made  visible, 
Including  the  rendering  of  a  fairly  accurate  representation  of  what  documents  will 
bok  like  if  printed.  The  graphical  input  device  facilitates  sketching,  as  well  as, 
pointing  and  selection  tasks. 

^[Cole69]  describes  the  design  of  a  simple  editor  using  proofreading  symbols. 
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The  MMS  presents  a  conceptual  model  that  resembles,  in  a  restricted  sensed  a 
paper  office.  The  MMS  operations  are  performed  by  direct  manipulaton  of  office 
objects  as  in  the  physical  office.  Even  for  text  processing  operations,  the  use  of 
physical  actions  is  extended  to  these  operations  through  the  proofreading  metaphor. 
As  a  result,  the  MMS's  mode  of  interaction,  in  the  context  of  the  conceptual  model, 
reinforces  similarities  between  the  manual  system  and  the  MMS.  Based  on  the  choice 
of  this  conceptual  model  and  mode  of  interaction,  it  seems  intuitive  and  consistent  in 
the  MMS  to  specify  first,  the  domain  of  the  operation  and  then  the  operation. 

The  MMS  pools  all  frequently  used  workstation  operations  into  the  default 
environment  (described  in  Section  3)  and  hides  facilities  that  are  Infrequently  used 
(e.g.,  template  design,  procedure  definition)  or  are  restricted  to  certain  elite  users. 
To  switch  to  these  other  facilities,  an  appropriate  workstation  operation  is  specified. 
This  technique  facilitates  extensions  to  the  system  since  new  facilities  can  be 
accommodated  by  providing  a  new  workstation  operation  that  will  switch  the  user  to 
the  new  environment. 


Two  different  techniques  are  used  for  specifying  certain  MMS  commands  -  menu 
selectkxi  and  character  sketching.  This  is  intended  to  make  sketching  commands 
easier  to  learn  and  use.  They  are  easy  to  learn  because  the  sketching  commands 
have  been  appropriately  chosen  to  resemble,  and  in  some  cases,  are  identical  to,  the 
standard  proofreading  symbols  [RandBO,  AsheSO].  The  proofreading  metaphor  helps 
place  the  electronic  text  processing  operations  in  a  more  familiar  context  for  the 
user  since  for  many  of  the  MMS  users,  their  expertise  and  experience  with  text  pro¬ 
cessing  systems  will  be  limited.  They  are  easy  to  use  because  the  symbols  require 
simple,  short  strokes  that  are  easy  to  draw.  Menu  selection  for  sketching  commands 
is  provided  as  a  teaching  and  reference  aid  to  allow  naive  users  to  familiarize  them¬ 
selves  with  the  character  symbols.  However,  as  the  user  becomes  familiar  with  the 


Sjms 


models 


only  a  small  aspect  of  the  physical  office. 
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symbols  and  requires  more  speed,  character  sketching  can  be  chosen  instead.  By 
binding  operand  and  command  specification  as  one  continuous  fluid  gesture,  there  is 
no  noticeable  delay  between  operand  and  command  specification  as  in  menu  selec¬ 
tion.  Since  the  command  set  is  small  and  the  symbols  are  simple,  it  is  reasonable  to 
expect  the  character  recognizer  to  provide  reasonable  response  time.  As  the  user 
adapts  to  the  sketching  technique,  he  can  push  for  more  speed;  albeit  as  quickly  as 
the  recognizer  can  recognize  the  symbols. 

The  MMS  enhances  the  usability  of  the  system  and  adds  consistency,  as  well 
by: 

o  providing  non-application  specific  tools  (i.e.,  support  tools),  and 
o  exploiting  some  of  the  application-specific  objects  for  other  purposes. 

MMS  Support  Tools 

A  profiling  facility  that  allows  the  user  to  customize  the  MMS  user  interface  to 
his  personal  preferences^.  The  features  that  the  user  can  choose  are: 
o  Menu  selection  or  character  sketching  for  text  processing  commands, 
o  Shorthand  form  or  long  form  for  command  specification.  The  shorthand  form  is  a 
macro  for  two  or  more  commonly  used  operations, 
o  Cor.firmation/no  confirmation  of  the  text-processing  and/or  workstation  operatbns. 
o  Placement  of  objects  before  or  after  the  selected  target.  This  eliminates  the  artifi¬ 
cial  distinctions  associated  with  text  placement  (e.g.,  insert  and  append)  and 

allows  the  user  tc  choose  the  preferred  manner  of  text  placement®, 
o  Screen  attribute  (e.g.,  black  on  white  screen),  cursor  attribute  (e.g.,  cursor  hides 
what  it  passes  over),  and  suppression  of  system  warnings  and  errors. 

User  aids  that  provide  assistance  and  safeguard  mechanisms  (i.e.,  HELP,  UNDO, 
CONFIRM,  and  ABORT)  which  are  intended  to  alleviate  the  user's  anxiety  when  using 

^Thls  facility  is  available  In  some  text-editing  system-s  [MeVa82] 

®  the  VMS  provides  tvjc  different  f/e/d  delimiter  Icons  (Figure  5)  to  delimit  the  start  and  end  of  text 
In  a  form  field  which  can  be  selected  for  Insert  before  first  or  append  after  the  last  piece  of  text  In  the 
field. 
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the  system.  Other  aids  compensate  for  human  limitations  (i.e.,  global  searching  and 
substitutions)  and  limitations  in  screen  real  estate  (i.e.,  scrolling  and  thumbing). 

Two  forms  of  feedback  [NeSp79]  are  present  in  the  MMS  (i.e.,  user  and  system). 
User  feedback  is  related  to  the  user's  actions  and  includes  echoing  all  inputs,  selec¬ 
tions,  and  position  of  the  cursor,  as  well  as  displaying  error  messages  for  mistakes. 
Different  cursors  (Figure  6)  are  used  to  Identify  the  objects  that  can  be  selected 
(e.g.,  menu  cursor  for  selecting  menu  Items).  This  allows  the  user  to  associate  the 
objects,  and  hence  the  type  of  operation  (i.e.,  scroll  or  select)  that  can  be  per¬ 
formed.  For  example,  when  the  cursor  is  in  a  scroll  region,  the  appropriate  form  of  the 
scroll  cursor  appears.  As  well,  the  MMS  highlights  objects  (i.e.,  with  a  box)  to  indi¬ 
cate  which  objects  are  selectable  in  the  current  context  (e.g.,  the  appropriate  target 
objects  that  a  data  icon  can  be  moued  to).  System  feedback  indicates  the  progress 
of  the  system's  actions  by  displaying  intermittent  messages  or  a  busy  bee  buzzing 
around  [ScMA82]  when  the  system  is  executing  a  time-consuming  operation  (Figure 
7).  This  animation  is  an  invaluable  feedback  to  the  user  that  the  system  is  not  in  a 
hung  state. 

Extending  Application-Specific  Objects 

The  skeleton,  aside  from  providing  an  alternate  view  of  the  document,  is  used 
for  the  thumbing  operation  (l.a,  to  Jump  directly  to  various  portions  of  the  document 
Instead  of  scrolling  incrementally)  and  visual  feedback.  The  items  In  the  skeleton 
may  also  be  selected  as  operands  in  text-processing  operations  (e.g.,  a  paragraph  of 
the  text  with  one  button  selection  versus  delimiting  the  text  making  up  the  para¬ 
graph). 

Forms  are  windows  into  the  data  from/to  which  the  user  may  retrieve  or 
add/modify  information.  In  command  specification,  a  form  can  be  used  to  provide 
operand  Information  and  also  a  flexible  and  effective  mode  of  input.  This  technique 
provides  the  user  with  flexibility  as  to  the  order  in  which  information  is  entered,  a 
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flexibility  absent  in  fixed,  one-dimensional  input  schemes. 

Transcript  files  are  maintained  to  facilitate  undo  operations.  Operations  back  to 
the  most  recent  checkpoint  can  be  undone  by  reversing  the  operations  that  are 
logged  in  the  transcript  file.  As  well,  the  transcript  files  are  exploited  by  the  HELP 
facility  to  provide  users  with  a  list  of  recent  operations  whenever  they  want  a  his¬ 
tory  of  the  operations  performed. 

5.  Conclusion 

In  this  paper,  we  demonstrated,  using  the  MMS  user  interface,  that  design  tech¬ 
niques  from  Human  Factors  can  be  applied  or  adapted  to  Office  Information  Systems 
to  enhance  their  usability.  It  office  systems  are  to  gain  widespread  acceptance  and 
use,  more  work  needs  to  be  done  on  developing  techniques  to  make  them  user- 
friendly  and  easy  to  learn  and  use.  To  gain  insight  about  the  various  designs  and 
techniques  that  should  be  used  in  an  office  system,  we  need  to  study  and  evaluate 
them  via  human  factors  methods. 

We  are  implementing  this  user  interface  in  the  C  programming  language  on  a  SUN 
personal  workstation  [Sun  82].  A  large  bit-map  display  (1024x800  pixels)  and  a 
mouse  will  serve  as  the  new  output  and  input  device^.  Our  objective  is  to  provide  a 
system  on  which  to  test  and  evaluate.  Informally,  this  interface.  We  would  also  like 
to  examine  the  viability  of  character  sketching  and  possible  extensions  to  the  sys¬ 
tem  to  support  such  tools  as  message  template  design  and  image  querying  [Woo83, 
Econ82]. 

6.  References 

[Ashe72]  ASHE,  G.  Good  Writing  For  All  Occasions.  Coles  Publishing  Company 
/./Vn/tecr,  Toronto,  '^972. 

[Cole69]  COLEWAN,  M.L.  Text  Editing  on  a  Graphic  Display  Device  Using  Hand- 
Drawn  Proofreader's  Symbols.  Pertinent  Concefyts  in  Computer  Graph¬ 
ics:  Proceedings  of  the  2nd  University  of  Illinois  Conference  on  Com¬ 
puter  Graphics.  Edited  by  M.  Faiman  and  J.  Nievergelt,  1969. 

^AmocLup  of  this  user  Interface  was  Irr^jlenented  on  the  PERQ  without  character  sketching. 


- 11  - 


[DeJoSO] 

[Econ82] 

[EIBe82] 

[Kom79] 

[Lamp78] 

[Lee  83] 

[LDch81] 

[LDcld83] 

[MeVa82] 

[NeSp79] 

[Rand80] 

[RoSh82] 

[ScMA82] 

[Shne83] 

[S1KV82] 

[Sun  82] 
[TRGN82] 

[Tslc80] 

[Tslc81  ] 


DEJONG,  P.  The  System  for  Business  Automation  (SBA):  A  Unified  /.ppli- 
cation  Development  System.  Proceedings  iFIP  Cortgress  1980,  pg. 
469-474. 

ECONOMOPOULOS,  P.  An  image  Database  Management  System.  M.  Sc. 
thesis  (1982),  Department  of  Computer  Science,  University  of  Toronto. 

ELLIS,  C.A.  and  BERNAL,  M.  Officetalk-D:  An  Experimental  Office  Infor¬ 
mation  System.  Proceedifigs  of  SIGOA  Conference  on  Office  Informa¬ 
tion  Systems^  University  of  Pennsylvania.  June  21-23,  1982.  pg. 
131-140. 

KORNATOWSKI,  J.Z.  The  MRS  User's  Manual.  CSRG,  University  of 
Toronto. 

LAMPSON,  B.W,  Bravo  Manual,  In  Alto  User's  Handbook,  Xerox  Palo  Alto 
Research  Center,  3333  Coyote  Hill  Road,  Palo  Alto,  California. 
November  1978,  pg.  31-62. 

LEE,  A.  A  Query  and  Editing  Language  for  a  Message  Management  Sys¬ 
tem.  M.  Sc.  thesis  (1983),  Department  of  Computer  Science,  Univer¬ 
sity  of  Toronto. 

LOCHOVSKY,  F.H.  Human  Factors  Issues  In  Office  Information  Systems. 
Proceedings  International  Congress  on  Applied  Systems  Research  and 
Cybernetics,  Acapulco,  Mexico.  Dec.  12-15,  1 980. 

LODDING,  K.  N.  Iconic  Interfacing.  lEFE  Computer  Graphics  and  Appli¬ 
cations.  March/April,  1  983. 

MEYROWITZ,  N.  and  VAN  DAM,  A.  Interactive  Editing  Systems.  ACM 
Computing  Surueys,  September,  1982.  Volume  14,  No.  3. 

NEWMAN,  W.M.  and  SPROULL,  R.F.  Principles  of  Interactive  Computer 
Graphics  (2nd  ed.).  Computer  Science  Series,  McGraw-Hill  Book  Co, 
1979. 

The  Random  House  Dictionary.  (J.  Stein,  editor),  BaJIantine  Books,  New 
York,  1  980. 

ROWE,  L.A.  and  SHOENS,  K.A.  A  Form  Application  Development  System. 
Proceedings  ACM  SJGMOD  Conference,  1 982. 

SCELZA,  D.A.;  MYERS,  B.A.  and  AMBER,  B.  PERQ  Introductory  User 
Manual.  Three  Rivers  Computer  Corporation,  1 982. 

SHNEIDERMAN,  B.  Direct  Manipulation:  A  Step  Beyond  Programming 
Languages.  University  of  Maryland,  1983. 

SMITH,  D.C.S.;  IRBY,  C.;  KIMBALL,  R.;  VERPLANK,  B.;  and  HARLEM,  E. 
Designing  the  Star  User  Interface.  BYTE,  April  1982.  Volume  7,  Number 
4. 

Sun  Microsystems  Inc.  The  Sun  Workstation  Architecture,  1982. 

TSICHRITZIS,  D.;  RABITTI,  F.A.;  GIBBS,  S.;  NIERSTRASZ,  O.;  and  HOGG,  J. 
A  System  for  Managing  Structured  Messages.  IEEE  Transactions  on 
Communications,  January  1982.  Volume  30,  Number  1. 

TSICHRITZIS,  0.  OFS:  An  Integrated  Form  Management  System. 
Prooyedings  Sixth  Inter  nation  Conforonco  on  Uery  Largo  Data  Bases, 
1981.  pg.  161-166. 

TSICHRITZIS,  D.  Integrating  Data  Base  and  Message  Systems. 
Proceedings  International  Conference  on  \/LDB,  Cannes,  France.  Sep¬ 
tember  1981. 


-  12  - 


[TsLo80]  TSICHRITZIS,  D.C.  and  LOCHOVSKY,  F.H.  Office  Information  Systems: 

Challenge  for  the  80's.  Proceedings  of  the  IEEE,  1980.  Volume  68, 
Number  9.  pg.  1 054-1  059. 

[Woo83]  WOO,  C.  A  Communication  Base  Design  System  for  a  Message  Manage¬ 
ment  System.  M.  Sc.  thesis  (1983),  Department  of  Computer  Science, 
University  of  Toronto. 

[Zloo76]  ZLOOF,  M.  Query  By  Example.  Proceedings  NCC,  44.  May  1975. 


-13- 


MEMO 


To: 


From: 


Date: 


Subject: 


V'iPl-n-,  : 


To: 


Dale: 


From: 


fsubje^ 


msssmBmmmm. 


\  \ 


k. 


M  g 


Figure  1 :  A  Mockup  of  MMS  screen  layout 


-  14  - 


FORMAT 


Font  Size 
Font  Type 
Face  Detail 
Base-Line  Spacing 
Line  Spacing 
Indent 

Lett  Margin  Indent 

Right  Margin  Indent 

Header  Indent 

Footer  Indent 

Ml i gnment 

Fill 

Item ize 

Itemize  Indent 
Break  Before 
Break  After 


12 


Italic 


Bold 


Box 


Embolden 


I  Italic  I 


Reverse 


lihderlift^ 


IS 


Double 


+.5  inch 


+1  inch 


-1  inch 


+1.5  inch 


-1  inch 


Center 


On 


1  Flush  Left  1 

Flush  Risht 

Justify 

I  — 1 

Bullet 

Dash 

Label 

Number 

0 


Figure  2:  Format  System  Form 


16- 


GLX)BAL  QUERY 


LOCATE 


TRACE 


RETRIEVE 
Hold  In: _ 


MEMO 


To: 


From: 


Date: 


Subject: 


Rgure  3:  Query  System  Form 


-  16  - 


FIND 


j 

1  START 

r  '  - — - n 

STOP 

CANCEL 

L 

Look  For; 


REPLACE 


Chane^e  To: 

CONFIRM 

Figure  4:  Find  System  Form 


-  17  - 


►  ^ 

Figure  5:  Field  Delimiter  Icons 


r  1  ~  - 

up  down  left  right 

Scroll  Cursors 


pointing  pencil  menu 
in  hand 

Selection  Cursors 


Figure  6:  MMS  Cursors 


Figure  7:  Busy  indicator 


-18- 


OPERATION 

CHARACTER 

Add 

/ 

Delete 

Replace 

Alter  Font 

/W\ 

Alter  Type  Face 

D 

Alignment 

Paragraph 

No  Paragraph 

Move  Right 

Move  Left 

Add  Space 

1 

Delete  Space 

y 

Delete  Blank  Lines 

c 

Add  Blank  Lines 

> 

Table  1 :  MMS  Text  Formatting  Character  Commands 


A  Graphical  Queiy  Language  for  Entity-Relationship 

Databases 

2h'i-  Qian  3iang] 

Mberto  0.  Mendelzon 


February  1983 

Computer  Systems  Research  Group 
University  of  Toronto 
Toronto.  Canada  MSS  1A4 

ABSTRACT 


We  describe  gql/ER,  a  graphics-based  system  for  querying  entity- 
relationship  databases.  The  user  sees  at  all  times  a  picture  of  the 
database  diagram  on  a  screen  and  poses  queries  by  marking  nodes 
on  the  diagram  using  a  mouse.  We  apply  the  concept  of  maximal 
objects  to  find  a  default  connection  among  any  set  of  nodes  in  a 
database  diagram. 

1.  Background 

While  interactive  access  to  databases  is  widely  believed  to  be  useful  and 
desirable,  there  has  been  little  success  so  far  in  producing  general  purpose 
interactive  interfaces.  It  is  our  impression  that,  in  practice,  when  interactive 
access  is  provided  at  all,  it  is  through  special  purpose  front  ends  built  on  top  of 
the  general  database  facilities,  even  when  these  facilities  are  supposed  to  be 
"user  friendly"  query  languages. 

In  examining  the  exceptions  to  this  rule,  we  have  extracted  several  guide¬ 
lines  for  what  seems  to  make  an  interface  useful. 


Navigation  Aids 

All  the  systems  we  consider  successful  give  the  user  some  help  in  navigat¬ 
ing  through  the  database  schema.  For  example.  QBE  [Z]  displays  several 
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relation  skeletons  that  act  as  visual  reminders  of  the  structure  of  the  database. 
The  spatial  database  system  SDMS  [H]  is  wholly  based  on  visual  aids  for  naviga¬ 
tion  Ihe  GUIDhi  system  [WK]  displays  the  schema  diagram  at  various  levels  of 
abstraction  to  aid  in  query  formulation.  The  language  for  Telidon-like  environ¬ 
ments  described  in  [LT]  uses  a  spaceship  metaphor  for  facilitating  user  naviga¬ 
tion  through  the  database.  The  problem  of  navigation  is  attacked  in  a  very  dif¬ 
ferent  way  by  the  universal  relation  interfaces  [U],  that  try  to  do  away  with 
navigation  whenever  possible  by  presenting  a  single-relation  user  interface. 

Graphics 

Again,  the  table  skeletons  and  condition  boxes  of  QBE  were  an  early 
attempt  to  exploit  the  two-dimensional  nature  of  terminal  screens.  Graphics 
have  been  incorporated  in  many  interactive  systems;  as  navigation  aids,  as  in 
SDMS  or  GUIDE,  as  output  presentation  tools,  as  in  SDMS,  or  as  aids  in  con¬ 
structing  queries.  as  in  CUPID  [MS]. 

Browsing 

The  paradigm  of  careful  construction  of  a  complex  query,  followed  by  exe¬ 
cution  Eind  possibly  iteration  of  the  process,  resembles  batch-oriented  debug¬ 
ging  more  than  dynamic  interaction.  In  contrast,  database  editors 
[CA.SK,M,WK]  have  emphasized  the  piecemeal  construction  of  queries  to  the 
point  where  a  user  can  browse  through  the  database  with  little  effort.  It  is 
hoped  the  feeling  when  using  such  a  system  will  be  more  like  driving  a  respon¬ 
sive  sports  car  than  setting  in  motion  a  sixteen-wheel  truck. 

Conciseness 

Verbose  query  languages  may  be  useful  for  readability  in  a  programming 
environment,  but  interactive  systems  seem  to  require  much  higher  bandwidth 
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in  user  reqiiest  formulation  [LT].  Concise,  editor-like  languages  [SK.M]  and 
graphical  inpait  devices  [WK.  CA]  have  been  used  to  improved  bandwidth. 

Data  Model 

Even  if  users  are  expected  to  have  some  degree  of  computer  familiarity,  we 
can  hardly  require  them  to  be  familiar  with  low  level  details  of  database  imple¬ 
mentation.  Thus,  all  systems  we  have  mentioned  use  relatively  high-level  data 
models,  ranging  from  the  relational  to  entity-relationship. 

2.  System  Overview 

In  this  paper,  we  describe  a  graphics-based  entity-relationship  query  sys¬ 
tem  called  gql/ER.  Its  design  resulted  from  the  observations  above  plus  the 
availability  in  our  environment  of  graphics-based  software  for  displaying,  edit¬ 
ing  and  translating  entity-relationship  diagrams  [CL,WM].  The  user  is  presented 
with  a  picture  of  an  E-R  database  scheme  on  a  graphics  screen  (Fig.l).  Queries 
are  formulated  by  pointing  to  nodes  (entities  or  relationships)  to  be  included  in 
the  query,  using  a  mouse-like  device.  Conditions  on  the  nodes  are  specified  by 
filling  out  forms.  At  any  time,  the  user  may  request  execution  of  a  query  as 
currently  specified  and  continue  refining  it  after  looking  at  the  output.  There 
are  two  modes  of  query  interpretation:  manual  and  automatic.  In  automatic 
mode,  gql  tries  to  answer  ambiguous  queries  by  finding  a  default  sub-network 
connecting  a  given  set  of  nodes.  In  manual  mode,  the  user  specifies  the  con¬ 
nection  between  all  the  selected  nodes  uniquely. 

This  design  addresses  in  an  obvious  way  the  considerations  of  graphics  use 
and  choice  of  data  model.  Navigation  is  simplified  in  two  ways.  One  is  the 
display  of  the  diagram  on  the  screen,  acting  as  a  logical  map  of  the  database. 
The  other  is  the  provision  of  default  connection  paths  that  alleviate  the  need 
for  explicit  navigation.  The  use  of  the  mouse  and  form-filling  techniques  makes 
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Fig.l  shx)ws  the  query  menu  of  the  system.  The  mode  selection  command 
sets  the  mode  to  maanual  or  automatic.  TTie  query  operations  union,  intersec¬ 
tion  and  difference  are  used  in  manual  mode  to  construct  complex  queries,  as 
will  be  explained  below.  A  set  of  control  operations  is  provided  to  explore  the 
structure  of  entity  and  relationship  sets  or  to  change  the  position  or  scale  of 
the  E-R  diagram. 

An  eleTnerdary  query  is  specified  by  marking  a  set  of  nodes  (entities 
and/or  relationships)  on  the  screen  and  filling  out  one  or  more  forms  for  each 
node  where  additional  conditions  ere  desired.  A  node  is  marked  by  moving  the 
cursor  to  it  with  the  mouse  and  pressing  a  button;  selected  nodes  are 
highlighted  on  the  screen,  althougli  this  does  not  show  in  our  hard  copy  figures. 

As  shoYm  in  Figure  2,  below  the  menu  area,  a  "stack"  of  one  or  more  forms 
for  each  selected  node  is  displayed,  with  the  one  currently  being  modified  on 
top  of  the  stack.  Forms  are  similar  to  QBE  relation  skeletons.  They  contain  a 
title,  which  is  the  name  of  the  associated  entity  or  relationship,  and  a  field  for 
each  attribute  of  the  entity  or  ri  lationship.  The  user  can  enter  expressions 
constructed  of  consteints  and  variables  to  qualify  the  query  and  also  specifies 
what  fields  should  be  output.  The  query  can  be  edited  at  any  time  by  moving 
forms  in  and  out  of  the  stack,  modifying  them,  and  marking  and  unmarking 
nodes. 

The  interpretation  of  the  query  defined  by  a  set  of  marked  and  qualified 
nodes  depends  on  whether  the  mode  is  automatic  or  manual,  as  explained  in 
the  next  two  sections.  In  defining  .he  semantics  of  queries  below,  we  will  talk  of 
"joining"  nodes  of  the  diagram  anti  applying  other  relational  algebra  operators. 
We  use  this  terminology  for  convenience,  since  our  system  uses  an  underl3nng 
relational  representation  to  store  the  database.  The  mapping  from  the  E-R 
diagram  to  the  relational  schema  is  fairly  standard  and  is  described  in  [WM]. 
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3.  Automatic  Mode 

We  provide  a  notion  of  default  connection  among  a  set  of  entities,  to  free 
the  user  from  one  form  of  navigation  on  the  database  schema.  In  general, 
there  may  be  several  plausible  connections  for  a  given  set  of  entities  and  rela¬ 
tionships,  and  the  user  must  be  able  to  specify  any  one  of  them.  It  follows  that 
there  is  no  way  the  system  can  correctly  infer  in  all  cases  the  user's  intended 
query.  However,  we  use  ideas  from  dependency  theory  to  find  a  "most  plausible" 
connection  and  use  it  as  a  default  which  the  user  cein  override. 

In  relational  database  theory,  lossless  joms'[U]  are  considered  a  useful 
guideline  for  finding  semantically  correct  interpretations  of  non- procedural 
queries.  Intuitively,  two  relations  have  a  lossless  join  if  from  the  existence  of  a 
pair  of  matching  tuples  taken  from  each  relation  we  can  infer  the  existence  of 
the  tuple  that  is  their  join.  In  particular,  we  apply  the  notion  of  "maximal 
object"  proposed  in  [MU].  There  an  object  is  a  database  relation.  A  maximal 
object  is  constructed  by  starting  with  an  object  and  "growing"  it  into  a  maximal 
object.  Objects  are  added  to  the  maximal  object  being  constructed  as  long  as 
the  new  object  joins  losslessly  with  the  objects  already  in  the  set. 

In  our  context,  an  object  is  defined  as  a  relationship  set  together  with  all 
its  participating  entity  sets.  We  use  the  cardinalities  on  the  edges  of  the 
diagram  to  infer  lossless  joins  which  allow  us  to  grow  objects  into  maximal 
objects.  For  a  set  of  nodes  X,  we  take  as  the  connection  on  X  the  union  of  all  the 
maximal  objects  that  contain  X.  We  give  more  precise  definitions  below, 

If  E1,E2,...  En  are  the  entity  sets  participating  in  a  relationship  set,  and  En 
has  cardinality  one,  then  the  functional  dependency 

El  &  E2  &  ...  &En-l->En 


holds. 
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Note  that  we  may  never  deduce  from  the  cardinalities  functional  depen¬ 
dencies  that  involve  only  a  proper  subset  of  the  entities  that  involved  in  a  rela¬ 
tionship.  For  example,  suppose  that  in  a  3-ary  relationship  set,  the  participat¬ 
ing  entity  sets  are  El.  E2,  E3  .  No  matter  what  cardinalities  are  specified,  we 
may  not  deduce  facts  such  as  El">E2  or  E2— >E3. 

An  object  is  a  relationship  set  together  with  all  its  participating  entity  sets, 

A  set  of  objects  0  determines  an  object  B,  if  B  is  an  object  corresponding  to 
a  binary  relationship  set  (E1.E2),  and  0  and  B  have  only  one  common  entity  set, 
say  El,  where  El— >E2  holds.  In  this  case  we  write  0==>B. 

A  maximaL  object  starting  from  object  A  can  be  defined  by  the  following 
algorithm: 

MO:=A: 

while  there  is  an  object  B  such  that  MO=  =  >B  do 
MO  :=M0  u  B 

The  maximal  object  thus  defined  has  two  properties: 

l)The  join  of  all  the  relationship  and  entity  sets  in  the  maximal  object  is 
lossless, 
and 

2)The  subgraph  of  the  original  E-R  diagram  corresponding  to  the  maximal 
object  contains  no  cycles. 

Suppose  for  an  E-R  diagram,  the  maximal  objects  are  Ml.  M2.  ...Mn.  and  the 
corresponding  subgraphs  in  the  E-R  diagram  are  Gl,G2,...Gn.  For  a  set  of  nodes 
(entity  or  relationship  sets)  X,  consider  the  set  of  all  the  Gi  s  such  that  Xis  con 
tained  in  the  set  of  nodes  of  Gi.  By  observation  2)  above,  each  Gi  is  a  tree.  Let  Ti 
be  the  unique  subtree  of  Gi  that  contains  every  node  in  X  and  has  as  few  nodes 
as  possible.  The  set  of  all  the  Ti’s  is  the  connection  onX. 

We  csm  now  associate  a  relational  algebra  expression  with  a  query  as  fol 
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lows.  first,  construct  the  connection  on  the  set  of  marked  nodes  of  the  query. 
For  each  Ti  in  the  connection,  let  Ei  be  the  na.aral  join  of  all  the  nodes  in  Ti. 
LetE  be  the  union  of  all  the  Ei's.  The  expression  we  want  is  obtained  by  applying 
to  E  the  selections  specified  by  the  conditions  cr-.  the  forms  and  the  projections 
corresponding  to  the  attributes  marked  for  out]>  it.  We  will  give  some  examples 
in  Section  5. 

4.  Manual  Mode 

As  we  said  before,  the  default  path  only  ref  .ijcts  the  most  basic  connection 
among  a  set  of  nodes,  so  we  can  not  expect  automatic  mode  to  provide  the  right 
answer  in  every  case.  When  the  default  mode  faiis  to  answer  the  query,  the  sys¬ 
tem  will  turn  to  manual  mode.  The  user  can  e’so  force  the  system  to  turn  to 
manual  mode. 

In  manual  mode,  the  user  expresses  his/  er  query  by  indicating  all  the 
nodes  he; /she  wants  to  include  in  the  query  am'  specifying  the  selection  condi¬ 
tions  and  output  conditions  for  them.  Each  ele  j'.entary  query  is  interpreted  by 
conceptually  building  a  virtual  relationship  a  tiong  all  the  entity  sets  being 
marked  in  the  elementary  query,  and  then  ap,.. lying  selection  conditions  eind 
output  conditions  on  the  virtual  schema  that  -esults.  The  rules  for  building 
this  virtual  relationship  are  as  follows: 

Suppose  that  the  entity  sets  in  an  elemen  ary  query  are  El,  E2,...,  En.  and 

the  relationship  sets  Rl,  R2 . Rk.  Let  R  be  a  ^'■rtual  n-ary  relationship  on  the 

Ei’s.  If  all  the  Ei’s  are  distinct,  then  R  is  defined  as  the  natural  join  of  all  the 
Rj's.  IT  some  of  the  Ei’s  are  not  distinct,  then  Y-’-e  have  to  rename  entities  and 
the  relationships  they  take  part  in  to  make  all  nodes  distinct.  This  will  happen 
when  queries  need  to  specify  the  same  entity  io  different  roles,  as  some  exam¬ 
ples  in  Section  5  will  show.  We  then  define  R  as  the  natural  join  of  the  Rj’s  after 


renaming. 
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Once  we  have  the  virtual  relationship  R,  we  apply  selection  and  projection 
to  it  to  obtain  a  relational  algebra  expression  E  for  each  elementary  query.  The 
user  may  specify  several  elementary  queries  and  how  they  are  to  be  combined, 
i.e.  by  union,  intersection,  or  difference. 

6.  Examples 

Consider  as  an  example  the  diagram  of  Figure  3,  taken  from  [TL].  The  func¬ 
tional  dependencies  inferred  from  the  diagram  are  ^uard  -»  haspitoL,  doctor  -* 
hospital  ,  test  -*  lab,  test  -*  patient,  diagnosis  ->  patient  ,  pati/ent  -*  'ward,  staff  -* 
■ward.  The  maximal  objects  are: 

^h-M 

\  p-t,  l-t,  w-p.  h-w  I 
\  w-s,  h-w} 

\  p-d,  w-p,  h-w  } 

^  doctor-p,  h-d,  w-p  } 

\  doctor-p,  w-p,  h-w  } 

where  the  first  object  in  each  set  is  where  the  growing  process  steu^ts. 

Ql.  Rnd  the  labs  associated  with  ward  12. 

To  express  this  query,  the  user  can  mark  Tab'  and  'ward'  and  mark  for  out¬ 
put  the  'name'  field  of  the  lab  form,  and  enter  '12'  in  the  'number'  field  of  the 
ward.  The  only  maximal  object  that  contains  both  lab  and  ward  is  the  second 
one,  ^  p-t,  l-t,  w-p,  h-w  }.  Hence,  the  connection  path  is  ward-patient-test-lab, 
and  the  answer  will  be  the  set  of  labs  that  have  been  assigned  tests  for  patients 
of  ward  12.  Note  that  there  are  several  other  ways  of  bringing  labs  and  weirds 
together.  For  example,  we  could  have  joined  h-1  and  h-w,  producing  the  set  of 
labs  that  work  with  the  hospital  where  ward  12  is  located.  Intuitively,  this  con¬ 
nection  is  less  "tight"  than  the  one  given  by  the  maximal  object,  since  there  is 
a  more  specific  connection  between  labs  and  wards  through  patients  and  tests. 
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Or  course,  the  other  query  can  be  specified  by  using  manual  mode. 

Q2  :  List  the  doctors  who  are  treating  some  patient  that  Dr.  Best  is  treat¬ 
ing. 

Note  that  this  query  cannot  be  expressed  in  automatic  mode,  since  it 
requires  mentioning  one  entity  (doctors)  twice.  However,  it  cem  be  formulated 
in  manual  mode.  We  build  a  virtual  relationship  R  between  three  entities 
patient,  doctorl,  doctor2:  a  triple  (p,dl.d2)  is  in  R  if  doctors  dl  and  d2  are  both 
treating  patient  p.  We  can  then  select  from  R  all  triples  where,  say,  dl  =  ’Best'. 

In  gql,  this  query  is  constructed  by  marking  the  doctor  node  and  entering 
’Best’  in  the  name  field,  marking  the  doctor-p  node,  the  patieqt  node,  the 
doctor-p  node  again,  and  the  doctor  node  again.  The  last  occurrence  of  the  doc¬ 
tor  node  has  ’name’  marked  for  output. 

The  next  query  is  on  the  simple  schema  of  Figure  4. 

Q3.  Find  the  students  who  tutor  for  Black's  supervisor. 

This  query  can  be  expressed  by  building  a  ternary  virtual  relationship  R 
between  entity  sets  student  and  professor,  shown  in  dotted  lines  in  figure  4. 
Entity  set  student  will  participate  in  R  twice.  R  is  the  set  of  all  triples  (p,sl,s2) 
such  that  student  si  tutors  for  professor  p  and  p  is  student  s2’s  supervisor. 

In  gql,  this  query  is  expressed  by  marking  the  student  node,  entering 
'Black'  in  the  name  field,  marking  the  supervisor,  professor,  and  tutor  nodes  in 
sequence,  and  marking  the  student  node  again  with  the  name  field  marked  for 
output. 

6.  Implementation 

Our  implementation  has  taken  advantage  of  a  package  which  provides  the 
users  with  a  set  of  operations  to  define,  modify,  and  analyze  an  E-R  schema  and 
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FUgure  4 

translate  the  E-R  schema  into  relational  schemas  [LC][WM].  The  gql  system 
takes  as  input  the  relational  output  of  this  design  tool  and  maps  the  E-R  queries 
into  relational  queries.  These  are  expressed  in  the  query  language  of  the  rela¬ 
tional  database  s)rstem  Mistress  [Rh]  and  passed  to  this  system  for  execution. 
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A  prototype  version  of  a  subset  of  gql,  providing  only  manual  mode,  has 
been  implemented  on  a  PDP  11/45  under  Unix.  It  is  wnllon  In  C.  using  the  GPAC 
package  [R]  for  graphics.  The  display  device  is  a  Three  Rivers  Graphics  Wonder. 

7.  Conclusion 

We  have  described  a  system,  gql/ER,  for  general  purpose  interactive  query¬ 
ing  of  entity-relationship  databases.  The  main  ideas  in  this  work  are: 

•  Use  of  graphics  to  provide  a  navigation  map  of  the  database  schema. 

•  Use  of  graphic  input  devices  and  form-filling  to  provide  conciseness  and 
responsiveness. 

•  Incremental  query  construction. 

•  Default  connection  mechanism  to  reduce  the  need  for  navigation. 

The  GUIDE  system  [WK],  developed  independently  at  Lawrence  Berkeley 
Labs,  bears  a  close  resemblance  to  ours.  It  also  provides  a  useful  capability  for 
viewing  the  database  schema  at  various  levels  of  abstraction.  However,  it  does 
not  deal  with  the  multiple  connection  problem,  providing  only  the  equivalent  of 
our  manual  mode.  We  view  the  use  of  the  maximal  object  concept  for  this  pur¬ 
pose  as  the  main  techniced  innovation  described  in  this  paper. 
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Abstract 


A  message  is  a  means  of  communication  that  can  be  generalized  to  include 
most  office  communication.  Example  of  messages  are  letters,  memos, 
records,  pictures  and  voices.  In  this  paper,  a  system  for  interactively 
designing  message  templates  is  presented.  Methods  that  allow  a  user  to 
create,  maintain,  and  specify  authorization  and  constraints  to  a  message 
template  are  discussed.  The  discussions  also  include  a  user  interface  that 
allows  a  user  to  define  Virtual  Message  Templates,  (known  as  Views  in  Data 
Base  Management  Systems)  using  some  of  the  existing  Base  Message  Tem¬ 
plates,  (known  as  relations  in  Data  Base  Management  Systems). 
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1.0  Introduction 

Communication  is  a  fundamental  human  activity  and  is  vital  to  the  running  of  a  business  or 
organization.  A  message  Is  a  means  of  communication  that  can  be  generalized  to  include 
most  office  communication.  A  m2ssag2  management  system  (MMS)  is  an  office  information 
system  which  is  able  to  manage  both  structured  data  (e.g.,  records)  and  unstructured  data 
(e.g.  picture,  voice).  It  has  the  notion  of  addresses,  as  In  a  message  system,  as  well  as  the 
capabilities  to  manage  messages,  the  way  a  data  base  management  system  manages  struc¬ 
tured  data  [Martin  and  Tsichritzis,  1 982]. 

A  communication  base  is  the  medium  through  which  users  add  and  obtain  information  in  a 
message  management  system.  It  is  the  repository  for  messages  and  the  medium  of  communi¬ 
cation  in  the  system.  A  communication  base  design  system  (CBDS)  is  a  system  that 
allows  a  user  to  design  message  templates  (known  as  message  types)  and  to  map  these 
message  types  to  structures  that  implement  the  Communication  Base  [Woo,  1983]. 

The  person  that  administers  the  CBDS,  called  the  communication  base  administrator 
(CBA),  Is  responsible  for  the  creation,  maintenance,  security  and  integrity  of  the  communica¬ 
tion  base.  A  CBA  is,  therefore,  capable  of  performing  at  least  the  following  functions: 

1.  The  specification  of  the  layout  of  headings,  titles  and  other  information  that  will  appear 
statically  in  all  message  instances. 

2.  The  specification  of  the  layout  of  message  fields.  This  Includes  the  specification  of  the 
type  and  properties  of  each  message  field. 

3.  The  specification  of  access  rights  for  each  message  type  (i.e.,  the  users  who  are 
allowed  to  access  particular  message  types). 

4.  The  specification  of  constraints  for  each  message  type.  This  includes  value  constraints 
on  message  fields,  actions  that  should  be  taken  when  certain  conditions  are  satisfied 
and  automatic  filling  of  message  fields. 

6.  The  specification  of  routing  for  a  message  type.  By  associating  routing  with  each  mes¬ 
sage  type,  the  CBDS  assumes  the  responsibility  for  both  evaluating  the  current  message 
instance  state,  to  yield  the  next  destination  for  the  instance,  and  for  forwarding  the 
instance. 

In  this  paper,  we  describe  facilities  that  allow  the  CBA  to  perform  the  first  four  functions 
mentioned  above.  Routing  specification  is  described  elsewhere  [Mazer  and  Lochovsky, 
1983]. 
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2.0  System  Facilities 

One  of  the  main  goals  of  a  CBDS  is  to  allow  a  CBA  to  design  a  message  type  interactively 
(i.e.,  to  design  and  edit  message  template  layouts  while  they  are  being  displayed  on  the  ter¬ 
minal).  Interactive  template  design  systems  provides  a  better  tool  to  define  screens  than 
embedded  langauges  becasue  the  designer  can  change  the  screen  while  tooking  at  it,  rather 
than  having  to  compile,  link,  and  run  a  program  to  see  what  the  screen  looks  like  [Rowe  and 
Shoens,  1  982].  Hence,  graphical  user  interface  techniques,  such  as  the  icons  used  In  the 
Xerox  Star  [Smith  et  al.,  1982]  and  the  use  of  windows  [Tesler,  1981]  and  miniatures 
[Feiner,  Nagy  and  van  Dam,  1981]  to  minimize  modal  interaction,  have  been  used  extensively 
In  our  system. 

The  screen  used  by  the  system  is  a  one  and  a  half  page  screen  (i.e.,  13"  by  11").  The 
screen  layout,  shown  in  figure  1 ,  is  divided  into  five  areas: 


System  Operation  Area 

System  Message  Area 

Display  Area 

Miniature  Area 

System  Server  Area 

Figure  1  Screen  Layout 
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1.  The  system  operation  area  is  used  to  display  operations  that  allow  a  CBA  to  create  and 
update  a  message  type. 

2.  The  display  area  is  used  to  display  a  normal-sized  window  ^  that  is  operated  on  by  the 
CBA. 

3.  The  system  server  area  is  used  to  display  icons  of  system  server  instances  such  as  gar¬ 
bage  can,  file  cabinet,  and  printer  [Lee,  1983]. 

4.  The  system  message  area  is  used  to  display  messages  that  are  supplied  by  the  system. 

6.  The  miniature  area  is  used  to  display  iconic  representations  of  currently  active  windows 
that  can  be  operated  on  by  the  user. 

The  input  devices  consist  of  a  keyboard  and  a  three  button  mouse.  The  mouse  allows  the 
user  to  select  an  object  on  the  screen  and  to  manipulate  It  in  various  ways.  A  great  deal  of 
the  Interaction  required  to  design  a  message  template  merely  requires  the  user  to  select 
objects  on  the  screen  and  to  position  them  to  desired  locations.  For  example,  the  position  of 
a  message  field  in  a  message  template  Is  indicated  by  pointing  to  the  desired  position, 
entering  the  desired  background  text,  and  then  pointing  at  and  dragging  the  desired  field 
name  to  the  appropriate  location  [Woo,  1983]. 


2. 1  Message  Types 

There  are  two  kinds  of  message  types  allowed  in  the  communication  base,  namely  base  mes¬ 
sage  types  and  virtual  message  types.  In  data  base  terms,  a  base  message  type 
corresponds  to  the  stored  data  base  representation,  while  a  virtual  message  type 
corresponds  to  views  of  the  stored  representation.  That  is,  virtual  message  types  are  sup¬ 
ported  by  providing  transformations  of  base  message  types. 


Base  Message  Types 

When  creating  a  base  message  type,  the  CBA  needs  to  do  the  following: 

1.  specify  the  template  (i.e.,  layout)  for  the  message  types. 

2.  define  the  message  fields  for  the  message  type. 

3.  specify  the  location  on  the  message  templates  where  each  message  field  should  appear. 


A  window  is  a  rectangular  division  of  the  screen  that  can  be  used  to  display  one  set  of 
information. 
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To  specify  the  background  information  of  a  message  type  template,  the  CBA  simply  selects 
the  desired  place  In  the  display  area.  The  CBDS  responds  with  an  Input  mode  cursor  at  that 
position.  Any  text  that  the  CBA  enters  thereafter  is  considered  a  heading  or  title  in  the 

message  type  template.  Figure  2  ' '  shows  some  background  Information  specified  by  the 
CBA. 

A  message  field  has  to  be  defined  before  it  can  be  used.  To  define  a^essage  field,  the  CBA 
has  to  switch  to  the  Defining  Message  Held  system-supplied  form  as  in  figure  3  (This  is 
done  by  selecting  the  Defining  Message  Field  miniature).  All  defined  message  field  names 
then  appear  on  the  right  hand  side  of  the  message  type  system-supplied  form  (see  figure 
2). 

To  specify  the  display  position  of  a  message  field,  the  CBA  first  selects  the  message  field 
name.  This  causes  the  cursor  to  become  the  name  of  the  message  field.  The  CBA  then  holds 
the  cursor  button  down,  drags  the  message  field  to  the  desired  position  in  the  message  type 
template  area,  and  releases  the  button.  The  message  field  is  then  displayed  on  the  screen 
as  in  figure  4. 


Yirtued  Message  Types 

The  following  three  basic  transformations  are  supported  in  the  CBDS: 

1.  Projection 

2.  Restriction 

3.  Cross  Product 

Projection  is  implicit  in  the  selection  of  message  fields  that  has  to  be  done  by  the  CBA  in 
order  to  specify  the  layout  of  the  message  type  template.  If  the  CBA  does  not  select  all  the 
message  fields  in  a  base  message  type,  then  a  projection  has  been  done  to  that  base  mes¬ 
sage  type  on  the  message  fields  selected. 

In  order  to  retain  the  integrity  of  data  in  base  message  types,  all  primary  keys  have  to  be 
projected  from  a  base  message  type  when  defining  a  virtual  message  type  [Furtado,  Sevcik 
and  Dos  Santos,  1979]. 


The  screen  layout  in  the  figure  is  different  from  the  screen  layout  as  in  figure  1.  In 
the  actual  system,  all  miniatures  should  appear  to  the  left  of  the  current  system- 
supplied  form.  Due  to  the  limited  screen  space  of  the  system  supporting  the  prototype 
CBDS,  the  miniatures  are  shown  on  top  of  the  current  system-supplied  form  and  if  more 
than  five  miniatures  are  needed  at  the  same  time,  the  additional  miniatures  are  displayed 
to  the  right  of  the  current  system-supplied  form. 

*  The  form  supplied  by  the  CBDS  for  the  user  to  define  message  templates  is  called  the 
system-supplied  form. 
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In  a  data  base  query  language,  restriction  is  usually  done  using  a  'where  clause.  Since 
there  is  no  query  language  as  such  in  the  CBDS,  restriction  has  to  be  specified  by  filling  in 
the  condition  field  in  the  virtual  message  type  system-supplied  form.  Figure  5  shows  the 
virtual  message  type  template  which  is  selected  from  the  base  message  type  R1  with  the 
restriction: 


a2  >  500 

The  condition  can  be  any  valid  condition  in  a  MISTRESS  query  language  'where-claiLse 
[Rhodnius,  1  981  ]. 

In  specifying  a  virtual  message  type  template,  if  more  than  one  base  message  type  Is  used, 
then  the  transformation  Is  a  cross  product.  As  soon  as  the  CBA  selects  his  first  mes¬ 
sage  field,  the  system-supplied  form  displays  only  the  message  field  names  for  that  base 
message  type.  All  other  message  fields  disappear  except  for  the  base  message  type 
names.  If  the  CBA  selects  a  base  message  type  name,  then  a  new  virtual  message  type 
system-supplied  form,  which  is  labelled  as  virtual  message  type:  level  2,  will  appear  In  the 
miniature  area  (see  figure  6). 

Figure  6  shows  the  virtual  message  type  template  after  the  CBA  has  selected  aS  and  R2 
(i.e.,  the  CBA  is  trying  to  perform  a  cross  product  between  R1  and  R2).  R1  is  a  first  level  vir¬ 
tual  message  type  system-supplied  form  because  a2  was  selected  first.  R1  is  also  used  to 
denote  the  header  of  the  repeating  group  of  this  virtual  message  type. 

After  the  CBA  has  dragged  a  base  message  type  name  and  placed  it  inside  the  virtual  mes¬ 
sage  type  template,  the  size  of  the  window  used  to  display  the  repeating  group  needs  to  be 
defined.  A  very  simple  method  is  used  to  perform  this  task.  There  are  four  sides  in  a  v/mdow. 
The  width  of  the  window  will  expand  if  the  CBA  drags  the  right  hand  side  line  of  the  window 
to  the  right.  Alternatively,  he  can  expand  the  window  by  dragging  the  left  hand  side  line  of 
the  window  to  the  left.  A  similar  action  can  be  performed  to  expand  the  height  of  the  win¬ 
dow.  To  shrink  the  window,  the  CBA  simply  has  to  reverse  these  actions. 

Sometimes,  it  Is  desirable  to  move  the  entire  window.  This  is  done  by  positioning  the  cursor  in 
the  center  of  the  window  and  dragging  the  entire  window. 

After  the  CBA  has  selected  a  second  base  message  type  as  in  figure  6,  he  can  work  on  that 
base  message  type  by  selecting  the  miniature  for  the  corresponding  virtual  level  that  con¬ 
tains  the  base  message  type. 

This  same  operation  can  be  performed  for  as  many  levels  as  the  CBA  wishes  as  long  as  there 
is  enough  room  in  the  miniature  area  to  store  all  the  system-supplied  forms.  Hence,  If  R3  is 
selected,  then  a  third  level  virtual  message  type  system-supplied  form  will  appear  in  the 
miniature  area. 

If  more  than  one  repeating  group  is  required  in  the  same  level  (see  figure  7),  they  are  speci¬ 
fied  in  the  same  way.  The  little  triangle  on  the  top  right  corner  of  the  level  two  virtual  mes¬ 
sage  type  system-supplied  form  indicates  that  there  is  more  than  one  virtual  message  type 
system-supplied  form  at  this  level. 
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From  these  basic  transformations,  it  is  possible  to  synthesize  more  complicated  transforma¬ 
tions  such  as  joins.  In  this  paper,  we  had  presented  a  specification  method  for  each  basic 
transformation  so  that  the  order  of  performing  or  selecting  the  transformations  is  not  impor¬ 
tant. 

Virtual  message  types  are  supported  so  that  the  CBA  can  define  complex  message  types 
containing  repeating  groups  (or  tables).  As  in  a  data  base  environment,  updating  such 
transformations  creates  some  problems  of  data  Integrity.  However,  If  an  appropriate  user 
Interface  is  used,  as  in  our  CBDS,  then  the  CBA  can  be  forced  to  specify  the  virtual  message 
types  in  such  a  way  that  the  CBDS  can  detect  and  intercept  transformations  on  a  base 
message  type  that  would  lead  to  the  violations  of  data  Integrity. 


2.2  Authorization 

Security  has  been  a  major  issue  in  operating  systems.  Many  methods  have  been  proposed  to 
specify  the  access  rights  of  a  file.  For  example,  the  password  method,  the  access  control 
matrix  method  and  the  cryptographic  method.  All  these  methods  are  very  well  documented  in 
the  existing  literature  [Hoffman,  1973]. 

We  combined  the  Ideas  in  operating  systems,  as  well  as  functions  and  roles  in  an  office,  to 
specify  the  authorization  for  messages.  Aaents  are  introduced  to  model  individual  users  of 
the  communication  base,  and  office  roles  '  are  used  to  model  office  functions  done  by  an 
agent  [Martin  and  Tsichritzis,  1982].  The  use  of  an  agent  playing  roles  provides  logical 
Independence  In  specifying  the  authorization  for  a  message.  However,  an  agent  playing 
roles  does  not  provide  structures  like  the  hierarchy  of  an  organization.  Hence,  we  allow  a 
role  to  contain  other  roles.  In  this  case,  specialized  roles  or  generalized  roles  can  be  used  to 
simplify  the  specification  of  authorization  for  messages. 

As  an  example,  let's  consider  the  role  graduate  student  and  the  role  Computer  Science 
graduate  student.  The  role  Computer  Science  graduate  student  specializes  the  role  gra¬ 
duate  student.  However,  when  playing  the  role  Computer  Science  graduate  student  the 
agent  still  preserves  the  access  rights  of  the  role  graduate  student.  On  the  other  hand,  the 
role  graduate  student  generalizes  the  roles  Computer  Science  graduate  student,  History 
graduate  student  and  so  on.  Hence,  playing  the  role  graduate  student,  the  agent  is  not 
allow  to  access  messages  that  are  granted  to  only  the  role  Computer  Science  graduate 
student.  Therefore,  if  the  agent  wants  to  access  as  many  messages  as  possible,  he  will 
have  to  play  the  most  specialized  role  he  can  play. 

The  CBA  has  to  fill  out  the  following  form  to  define  a  role: 


^  It  is  likely  that  a  user  will  have  more  than  one  role.  For  example,  an  individual  may  play 
the  role  of  a  professor  in  the  Computer  Science  department  and  also  the  role  of  chairman 
of  the  Computer  Systems  Research  Group. 
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Role  Name  : _ 

Agents  Included  : . 

Roles  Included  : _ 

Agents  Excluded  : 
Roles  Excluded  :  _ 


Figures  System-supplied  form  to  define  a  role 

Commas  are  used  to  separate  the  agent  names  and  role  names.  By  defining  a  role  in  this 
way,  it  Is  very  easy  to  define  a  new  role  using  some  of  the  existing  roles. 

There  are  certain  restrictions  that  a  CBA  has  to  observe  when  filling  out  this  system- 
supplied  form.  The  most  obvious  conditions  are  that  the  agent  names  and  the  role  names  in 
the  included  and  excluded  sections  must  have  been  previously  defined.  Furthermore,  the 
agent  names  and  the  rde  names  in  the  excluded  sections  must  be  a  subset  of  one  of  the 
roles  in  the  included  section.  This  is  because  any  agents  or  roles  that  are  not  mentioned  in 
the  Included  section  are  implicitly  excluded.  Hence,  the  excluded  sections  are  used  to 
exclude  those  agents  or  roles  that  are  already  included.  However,  if  the  CBA  wants  to 
include  an  agent  or  a  role  that  belongs  to  a  role  that  is  excluded,  he  can  put  this  agent  or 
the  role  in  the  included  section. 

To  define  an  authorization,  the  user  needs  to  fill  out  the  form  shown  in  figure  9: 


Authorization  :  _ 

Roles  Included  : . 
Roles  Excluded  : 


Figure  9  System- supplied  form  to  define  an  authorization. 


tt 


We  assume  that  agents  are  basic  entities  within  the  system  and  are  avculable  for  use 
In  role  definition. 
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When  defining  an  authorization,  there  is  no  section  for  agents  to  be  included  or  excluded 
because  roles  are  used  to  refer  to  a  particular  function.  In  this  way  we  eliminate  the  need  to 
change  the  authorization  specification  when  an  agent  changes  his  role  in  an  office.  How¬ 
ever,  if  an  agent  name  is  used,  the  CBDS  will  assume  that  the  specification  means  the  agent 
playing  the  role  of  himself.  This  is  used  to  handle  access  right  specification  for  personal 
messages  for  that  agent  so  that  every  agent  in  the  CBDS  can  have  their  own  private  mes¬ 
sages  regardless  of  the  roles  they  can  play. 

The  term  can  play  a  role  identifies  the  set  of  roles  in  which  an  agent  is  included.  This  is 
important  because  if  an  agent  can  play  a  particular  role,  then  he  has  access  to  all  of  the 
messages  for  which  the  role  is  included  in  an  authorization  form.  If  a  role  is  not  specified  in 
the  roles  included  section,  agents  that  can  play  that  role  are  not  allowed  access  to  the 
message  unless  a  generalized  role  of  this  role  is  specified.  To  exclude  an  agent  from  having 
access  to  a  message,  when  one  of  the  roles  that  an  agent  can  play  has  access  to  it,  the 
agent,  or  a  specialized  role  that  includes  the  agent,  must  appear  in  the  roles  excluded  sec¬ 
tion  of  the  authorization  form. 


2.3  Constraints 

Constraints  have  been  studied  by  many  people  in  areas  like  data  base  management  and  pro¬ 
gramming  languages.  We  combined  some  of  the  ideas  from  value  constraints,  procedures  in 
form  systems  and  sta^e  dependent  conditions  [Ferrans,  1982]  to  form  our  constraints 
specification  language.  ' 

The  specification  of  constraints  can  be  viewed  as  consisting  of: 

Pre  condition-action 
Post  condition-action 

One  can  think  of  a  condition- action  unit  as  an  if  then  else  statement  (i.e.,  if  the  condition 
is  true,  then  perform  some  action(s),  otherwise  perform  some  other  action(s)).  If  the  condi¬ 
tion  gets  more  complicated  (i.e.,  it  is  a  selection  among  several  actions),  then  the 
condition- action  unit  is  like  a  case  statement  (i.e.,  depending  on  the  value  of  condition  a 
different  action(s)  will  be  performed). 

Constraints  can  be  specified  at  three  different  levels,  namely  the  message  type  level,  the 
message  instance  level  and  the  message  field  level.  If  constraints  are  specified  in  the  mes¬ 
sage  type  level,  then  the  constraints  are  applied  to  all  the  corresponding  message 
instances.  At  the  message  instance  level,  a  pre-condition  is  a  constraint  that  must  be 
satisfied  before  the  message  instance  can  be  used.  A  post-condition  is  a  constraint  that 
must  be  satisfied  after  the  message  instance  has  been  used.  To  be  more  precise,  a  pre¬ 
condition  w'ould  be  checked  at  message  creation  or  prior  to  use  of  a  message  while  a  post¬ 
condition  would  be  checked  during  compilation  (storage)  of  the  message  instance.  At  the 
message  field  level,  a  pre-condition  is  a  constraint  that  must  be  satisfied  before  filling  a 
message  field.  A  post-condition  is  a  constraint  that  must  be  satisfied  after  a  message  field 
is  filled.  The  pre-action  would  be  performed  if  the  pre-conditbn  is  satisfied.  Similarly,  the 


This  paper  presents  a  constraints  specification  language  for  message  types,  message 
instances  and  message  fields.  It  only  covers  the  specification  of  the  language.  Enforce 
ment  of  the  constraints  is  not  discussed  in  this  paper. 
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post-action  would  be  performed  if  the  post-condition  is  satisfied. 

There  is  an  inherent  pre-condition  constraint  at  the  message  type  level  because  authoriza¬ 
tions  are  used  to  insure  the  privacy  of  a  message.  Hence,  if  an  agent  is  not  allowed  to 
access  a  particular  message,  then  the  pre-condition  is  not  satisfied. 

At  the  message  instance  level,  the  CBA  is  concerned  with  the  following  pre-action/post¬ 
action: 

1.  ship  it  to  an  assigned  destination  [Hogg,  Nierstrasz  and  Tsichritzis,  1981]. 

2.  put  it  in  a  dossier  or  a  message  file. 

3.  make  multiple  copies  and  distribute  them. 

4.  generate  .messages  to  someone. 

At  the  message  field  level,  the  CBA  is  concerned  with  the  following  pre-actions/post- 
actions: 

1 .  Generate  error  or  warning  messages  to  users. 

2.  Generate  a  message  field  by  performing  some  arithmetic  operations  from  some  other 
message  fields  in  the  same  message  instance  ’  or  be  copying  from  some  other  mes¬ 
sage  field. 

3.  Assign  a  constant  to  the  message  field. 

The  pre-condition  and  post-condition  can  be  specified  in  one  of  the  following  ways: 

1.  use  a  simple  condition  expression  such  as 

meeting_date  =  "Aug.  19,  1981" 
where  "meeting_date"  is  a  message  field  name. 

2.  at  the  message  field  level,  check  to  see  whether  the  message  field  already  has  a 
value  entered. 

3.  use  a  MISTRESS  query  [Rhodnius,  1981]. 

4.  have  a  case  structure  to  perform  different  actions  according  to  different  conditions. 

5.  In  the  message  instance  level,  the  CBA  is  also  allowed  to  complete  an  origin  pseu¬ 
dosketch  [Hogg,  Nierstrasz  and  Tsichritzis,  1981]  to  specify  where  the  message 
came  from. 


t 


If  it  is  carefully  done,  the  CBA  can  take  message  fields  from  other  message  instances 
either  in  the  same  message  type  or  different  message  type. 
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Sometimes  it  is  necessary  to  perform  some  actions  depending  on  the  state  of  the  communi¬ 
cation  base  at  that  time.  For  example,  a  user  cannot  fill  out  a  sales  form  unless  there  are 
enough  parts  to  be  sold  to  the  customers.  Hence,  the  CBDS  extends  the  specification  of 
constraints  to  allow  querying  the  data  base  using  a  MISTRESS  query.  The  MISTRESS  query 
can  be  combined  with  some  operators  to  yield  a  boolean  condition.  This  Is  the  way  system  R 
specifies  Its  constraints  [Astrahan,  1976].  Some  examples  of  such  constraints  are: 

(select  count  from  orders)  =  (select  max  part^  from  inventory) 

(select  partjff  from  orders)  IS  IN  (select  part,^  from  inventory) 

(select  pan§  from  inventory)  IS  UNIQUE 
(select  count  from  visitjjst)  >  0 

Sometimes,  it  is  necessary  to  select  among  several  actions  under  some  conditions.  This  is 
the  situation  where  people  use  the  "case"  statement.  Consider  as  an  example  the  case 
statement: 

ca.se  (select  from  orders)  of 

(2,3,4)  :  actioni ; 

((2, 3, 4), (2,*, 5), (2, 5,6))  :  action2; 

(select  from  sales)  :  action3; 

default  :  display  "something  Is  wrong"; 

end 

If  select  from  orders  returns  only  one  message  instance  and  it  matches  (2,3,4),  then 
actioni  will  be  performed.  On  the  other  hand,  if  it  returns  only  one  message  instance,  and  it 
does  not  match  (2,3,4),  then  the  default  case  would  be  used  since  there  is  no  other  case 
label  with  only  one  message  instance. 

There  is  a  symbol  ♦  inside  the  second  message  instance  of  the  second  case  label.  When¬ 
ever  this  symbol  is  used,  it  matchs  anything.  In  the  example  above,  the  message  instance 
(2,*, 6)  v^'ould  match  any  message  instance  whose  first  message  field  has  the  value  2  .and 
whose  third  message  field  has  the  value  6. 

MISTRESS  queries  are  also  allowed  in  the  case  label.  Thus,  in  the  above  example,  if  the 
result  returned  by  the  condition  MISTRESS  query  matches  the  result  returned  by  the  case 
label  "select  from  sales",  then  actions  is  performed. 
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3.0  Implementation 

The  user  interface  for  the  CBDS  has  been  prototyped  on  a  Three  Rivers  Corporation  PERQ 
computer  using  PERQ  Pascal.  The  system  is  currently  being  implemented  on  a  SUN  worksta¬ 
tion  in  the  C  programming  language  under  the  UNIX  operating  system.  The  MISTRESS  rela¬ 
tional  data  base  management  system  is  being  used  as  the  underlying  storage  and  access 
mechanism  for  the  communication  base. 

The  information  required  to  map  base  message  types  to  relations  and  virtual  message  types 
to  base  message  types  Is  maintained  in  various  system  relations.  In  addition,  the  authoriza¬ 
tion  mechanism  and  the  constraint  mechanism  also  use  various  system  relations  to  maintain 
required  information.  This  provides  us  with  a  uniform  data  structure  and  access  mechanism 
for  implementation  [Woo,  1983]. 


User  Interface 

The  user  interface  program  consists  of  five  main  modules.  They  are: 

(1)  The  base  message  type  module 

(2)  The  virtual  message  type  module 

(3)  The  authorization  module 

(4)  The  constraint  module 
(6)  The  miniature  module 

Each  of  the  modules  can  call  any  other  module  (including  itself). 

The  base  message  type  module  is  used  to  define  a  base  message  type.  It  consists  of  four 
sub-modules.  They  are: 

(1)  Background  Information  handler 

(2)  Message  field  selection  handler 

(3)  Defining  message  field  module 

(4)  Miscellaneous  handler 

The  four  sub-modules  can  be  called  at  any  stage  of  the  specification  from  the  base  mes¬ 
sage  type  (i.e.,  the  communication  of  these  four  sub-modules  is  through  the  base  message 
type  module).  The  "background  information  handler"  handles  the  specification  of  all  the 
background  information.  The  "message  field  selection  handler"  lets  the  CBA  specify  the  posi¬ 
tion  of  the  selected  message  fields.  The  "defining  message  field  module"  is  the  module  that 
handles  the  definition  of  a  message  field  (i.e.,  the  system-supplied  form  that  lets  the  CBA 
define  a  message  field).  The  "miscellaneous  handler"  handles  all  the  remaining  information, 
such  as  the  base  message  type  name. 

Similarly,  the  virtual  message  type  module  has  the  following  modules  that  perform  the  specif¬ 
ication  of  a  virtual  message  type. 

(1)  Background  information  handler 

(2)  Message  field  selection  handler 

(3)  Relation  selection  handler 

(4)  Condition  handler 

(6)  Miscellaneous  handler 
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Modules  (1),  (2)  and  (5)  are  similar  to  the  corresponding  base  message  type  modules.  The 
relation  selection  handler"  is  used  to  define  repeating  groups.  This  includes  the  specifica¬ 
tion  of  the  screen  area  used  for  the  repeating  group  window.  The  "condition  handler"  is  used 
to  input  the  restriction  (or  selection)  operation  that  is  placed  on  a  base  message  type  (e.g., 
amount  >  500)  by  the  user. 

There  are  two  sub-modules  in  the  authorization  module.  They  are: 

(1)  Selection  of  authorization  handler 

(2)  Inclusions  and  exclusions  handler 

The  selection  of  authorization  handler  lets  the  CBA  select  the  kind  of  authorization  (e.g., 
read,  update,  mail)  that  he  wants  to  specify.  The  other  sub-module  handles  the  input  of 
inclusions  and  exclusions. 

The  constraint  module  allows  the  CBA  to  perform  the  specification  of  constraints  in  a  mes¬ 
sage  type,  message  instance  or  message  field. 

The  miniature  module  handles  the  stack  of  all  the  used,  but  unfinished,  system-supplied 
forms. 

The  prototype  user  interface  implementation  has  focused  on  the  main  functions  of  the 
design  and  specification  of  message  types.  Due  to  the  highly  structured  nature  of  the  user 
interface,  error  checking  on  actions  performed  by  a  CBA  is  minimal.  Due  to  the  unavailability 
of  a  graphical  package,  the  actual  shrinking  of  the  miniatures  is  not  done.  However,  the 
implemented  program  demonstrates  the  ideas  described  in  section  two. 


Authorization 

After  the  user  fill  out  the  role  definition  system-supplied  form,  the  system  stores  the 
system-supplied  form  by  linking  its  block  to  the  appropriate  place  in  the  role  network.  A 
block  will  contain  one  role  definition  and  pointers  to  agents  and  roles  included  and/or 
excluded  (see  figure  10). 


Pointers  to 
Agents 
Included 

Pointers  to 
Roles 
Included 

Pointers  to 
Agents 
Excluded 

Pointers  to 
Roles 
Excluded 

figure  10  Structure  of  an  authorization  block 


Hence,  a  simple  role  network  would  look  as  figure  1 1 . 
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Flgure  1 1  A  simple  role  network. 


Figure  10  and  figure  11  are  only  a  logical  view  of  the  data  storage  representation.  Physi¬ 
cally,  the  information  is  stored  in  the  data  base  using  system  relations. 

To  check  for  loops  during  modification  to  the  role  definition,  the  CBDS  uses  the  roles 
included  to  find  their  corresponding  blocks.  Then  it  uses  these  blocks  to  find  the  roles  that 
they  point  to.  If  one  of  the  role  names  that  a  block  points  to  is  the  same  as  the  role  name 
that  is  being  modified,  then  there  is  a  loop.  This  process  continues  until  no  more  pointers  can 
be  found  or  a  role  name  indicated  in  the  roles  excluded  section  is  the  same  as  the  role  name 
that  is  being  modified. 

To  identify  the  roles  a  user  can  play,  the  system  has  to  find  the  block  that  has  his  name  in 
the  agents  included  section.  Using  the  role  name  of  this  block,  the  system  then  finds  out  all 
the  blocks  that  point  to  this  block  (i.e.,  the  roles  that  have  this  role  as  a  subset).  Then  it 
uses  these  roles  to  find  the  blocks  that  point  to  these  other  roles.  This  searching  continues 
until  either  no  more  pointers  can  be  found  (i.e.,  the  root  of  the  tree  has  been  found),  or  the 
role  name  appears  in  the  roles  excluded  section. 
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4.0  Summary 

This  paper  has  presented  the  design  and  implementation  of  a  system  for  interactively 
designing  message  templates.  We  have  described  the  use  of  a  graphical  user  interface  to 
aid  the  user  in  designing  message  templates.  Furthermore,  via  a  user  interface,  the  system 
can  control  the  way  a  user  designs  message  templates  so  that  updates  through  virtual  mes¬ 
sage  types  can  be  properly  done.  Introducing  the  idea  that  a  user  can  play  certain  roles, 
authorization  can  be  specified  using  these  roles.  Also,  allowing  a  role  to  contain  other  roles 
simplifies  the  specification  of  authorization  for  the  user.  Finally,  a  constraint  language  has 
been  proposed  that  includes  decisions  to  be  made  according  to  the  contents  of  the  data 
base  at  the  time. 
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Abstract 


Security  has  been  one  of  the  major  topics  in  operating  systems.  We  com¬ 
bined  the  ideas  In  operating  systems  as  well  as  functions  and  roles  in  am 
office  to  specify  the  authorization  of  messages.  Agents  are  introduced  to 
model  individual  users  of  the  communication  base,  and  office  roles  are  used 
to  model  office  functions  done  by  an  agent.  The  use  of  agent  playing  roles 
provides  logical  independence  in  specifying  the  authorization  for  a  message. 
However,  agent  playing  roles  does  not  provide  structures  like  a  hierarchy  of 
an  organization.  Hence,  we  allow  a  role  to  contain  other  roles.  In  this  case, 
specialized  roles  or  generalized  roles  can  be  used  to  simplify  the  specifica¬ 
tion  of  authorizations  for  messages. 


1.  Introduction 

This  paper  discusses  a  method  for  specifying  access  rights  for  a  message  in  the 
Message  Management  System  (MMS).  This  is  done  by  introducing  the  concept  of  roles  in  an 
office.  However,  the  design  assumed  that  the  communication  base  design  system  (CBDS) 
only  runs  in  one  workstation  [Woo  83].  Hence,  the  semantics  of  authorization  in  mailing  a 
message  is  not  discussed  (see  section  10). 

Security  has  been  one  of  the  major  topics  in  operating  systems.  Many  methods 
have  been  proposed  to  specify  the  access  rights  of  a  file.  For  example,  the  password 
method,  the  access  control  matrix  method  and  the  cryptographic  method.  All  these  methods 
are  very  well  documented  in  the  existing  literature  [Hoff73]. 
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One  possible  authorization  specification  method  is  to  simply  list  for  every  user 
the  messages  ’  that  he  can  access.  There  are  several  disadvantages  to  this  method.  First, 
the  list  must  specify  the  level  of  access  rights  (i.e.,  message  type,  message  instance  or 
message  field).  Secondly,  deletion  of  a  message  implies  update  of  all  authorization  lists  for 
users  allowed  to  access  this  message.  Finally,  creation  of  a  new  message  requires  update 
of  all  authorization  lists  for  users  allowed  access  to  this  message. 

An  alternate  method  is  to  list,  for  every  message,  all  the  users  who  are  allowed 
to  access  the  message.  However,  this  method  does  not  fulfill  the  goal  of  easy  specification 
because  the  list  of  access  rights  for  some  messages  are  similar.  This  similarity  of  access 
rights  in  messages  is  due  to  the  nature  of  the  work  performed  in  an  office  by  the  office 
workers.  In  this  case  the  user  has  to  repeat  the  specifications  (except  for  some  minor 
changes)  for  all  these  messages.  Furthermore,  an  office  worker  might  change  his  responsi¬ 
bilities  because  of  promotions  or  company  re-organization.  In  this  case,  all  the  messages 
that  have  this  office  worker  in  their  authorization  list  have  to  be  changed.  Hence,  there  is  a 
need  to  group  users  into  groups  according  to  the  function(s)  they  perform  in  an  office  and  to 
use  this  functionality  to  perform  the  access  rights  specification.  This  can  be  done  by  using 
data  abstraction. 


2.  Agent  eoid  Roles 

In  data  structures,  abstraction  is  the  ability  to  hide  detail  and  concentrate  on 
general,  common  properties  of  a  set  of  objects  [TsLo82].  Therefore,  to  overcome  the  prob¬ 
lems  described  above,  two  abstractions  of  users  are  used.  Agents  are  used  to  model  indivi¬ 
dual  users  of  the  communication  base  [MaTs82],  and  office  roles  are  used  to  model  office 
functions  done  by  an  agent.  An  office  role  is  the  set  of  actions  and  responsibilities  associ¬ 
ated  with  a  particular  office  function  [MaTs82].  "Employee”,  "Manager",  and  "Chief  Program¬ 
mer"  are  ail  examples  of  office  roles.  If  there  are  five  people  that  perform  a  particular 
office  role  R,  then  R  is  associated  with  these  five  agents.  Any  time  a  role  R  is  used  in 
authorization  specification,  the  CBDS  automatically  associates  with  R  the  agents  that  play 
that  role. 


The  use  of  an  agent  playing  a  role  provides  logical  independence  in  specifying 
the  authorization  for  a  message.  For  example,  if  a  particular  message  is  only  accessed  by 
the  chairman  of  the  Computer  Systems  Research  Group,  then  the  role  chairman  of  CSRG 
can  be  used  without  having  to  know  what  individual  is  currently  chairman. 

It  is  likely  that  a  user  will  have  more  than  one  role.  For  example,  an  individual 
may  play  the  role  of  a  professor  in  the  Computer  Science  department  and  also  the  role  of 
chairman  of  the  Computer  Systems  Research  Group. 

In  our  authorization  specification  method,  the  user  only  needs  to  provide  the  role 
names  and  not  the  names  of  individuals.  However,  this  does  not  handle  more  complicated 
situations  such  as  that  of  a  company  organized  in  a  hierarchy  where  whoever  is  at  the  top 
of  the  hierarchy  has  access  to  all  of  the  information  of  the  roles  under  him.  It  also  does  not 
allow  for  the  case  of  a  matrix  organization  where  the  roles  are  defined  both  by  function  (row 
in  a  matrix)  and  by  product  (column  of  a  matrix). 


In  this  context,  the  word  message  means  message  type,  message  instance  and  mes¬ 
sage  field. 
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T^e  solution  to  this  problem  is  to  allow  a  role  to  contain  other  roles.  For  example, 
if  Joe  Smith  is  a  graduate  student  in  the  University  of  Toronto,  then  he  plays  the  role  gradu¬ 
ate  student  in  U  of  T.  But  the  role  graduate  student  in  U  of  T  consists  of  Computer  Sci¬ 
ence  graduate  students,  Business  graduate  students  and  so  on.  Hence,  if  someone  wants  to 
refer  to  all  U  of  T  graduate  students,  then  he  only  needs  to  specify  the  role  graduate  stu¬ 
dent  in  U  of  T.  In  this  way,  all  graduate  students  in  U  of  T  would  be  included,  regardless  of 
the  department  in  which  the  students  are  enrolled.  Therefore,  the  role  graduate  student  in 
U  of  T  generalizes  the  roles  Computer  lienee  graduate  student,  Business  graduate  stu¬ 
dent  and  so  on. 

This  mechanism  is  important  because  it  can  be  used  to  refer  to  a  set  of  roles 
without  worrying  about  the  details  of  the  agents  under  these  roles.  Hence,  when  using  the 
role  graduate  student  in  U  of  T,  one  hides  the  details  of  what  department  a  graduate  stu¬ 
dent  is  enrolled  in.  Also,  if  an  agent  only  plays  the  role  of  graduate  student  in  U  of  T,  then 
that  agent  is  only  allowed  to  access  messages  that  are  granted  to  the  role  graduate  stu¬ 
dent  in  U  of  T.  Messages  that  are  granted  to  only  the  role  Computer  Science  graduate 
student  cannot  be  accessed  by  that  particular  agent.  This  is  because  that  agent  does  not 
play  the  role  of  Computer  Science  graduate  student. 

Conversely,  the  role  graduate  student  in  U  of  T  is  too  general  when  someone 
wants  to  refer  to  only  the  graduate  students  in  a  particular  department.  Hence,  a  role  like 
Computer  Science  graduate  strident,  which  specializes  the  role  of  graduate  student  in  U 
of  T,  is  used. 

Specialized  roles  are  important  because  they  can  group  agents  into  a  smaller  set 
but  still  preserve  their  required  properties.  For  example,  Joe  Smith  may  be  able  to  play  both 
the  role  Computer  Science  graduate  student  and  the  role  graduate  student  in  U  of  T. 
The  role  Computer  Science  (Graduate  Student  is  a  specialized  role  of  the  role  graduate 
student  in  U  of  T.  However,  when  playing  the  role  Computer  Science  graduate  student, 
Joe  Smith  still  preserves  the  access  rights  of  the  role  graduate  student  in  U  of  T.  Hence, 
Joe  Smith  is  allowed  to  have  access  to  every  message  that  a  U  of  T  graduate  student  is 
allowed  to  access,  as  well  as  every  message  that  a  Computer  Science  graduate  student  is 
allowed  to  access.  However,  Joe  Smith  is  not  allowed  to  access  messages  that  only  Busi¬ 
ness  graduate  students  can  access. 


3.  Defining  a  Role 

Roles  within  organizations  determine  the  structure  of  the  organization.  Hence, 
the  definition  of  roles  and  agents  should  be  restricted  to  only  certain  authorized  people.  For 
those  people  that  are  authorized  to  define  roles,  they  have  to  fill  out  the  following  form: 
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Role  Name  : _ 

Agents  Included  :  . 
Roles  Included  :  _ 
Agents  Excluded  ; 
Roles  Excluded  :  _ 


3.1  S3rsteiii- supplied  form  to  define  a  role 

Commas  are  used  to  separate  the  agent  names  ^  and  role  names.  By  defining  a  role  in  this 
way,  it  is  very  easy  to  define  a  new  role  using  some  of  the  existing  roles. 

There  are  certain  restrictions  that  a  CBA  has  to  observe  when  filling  out  this 
system-supplied  form.  The  most  obvious  conditions  are  that  the  agent  names  and  the  role 
names  In  the  included  and  excluded  sections  must  have  been  previously  defined.  Further¬ 
more,  the  agent  names  and  the  role  names  in  the  excluded  sections  must  be  a  subset  of  one 
of  the  roles  in  the  included  section.  This  is  because  any  agents  or  roles  that  are  not  men¬ 
tioned  in  the  included  section  are  implicitly  excluded.  Hence,  the  excluded  sections  are  used 
to  exclude  those  agents  or  roles  that  are  already  Included.  However,  if  the  user  wants  to 
Include  an  agent  or  a  role  that  belongs  to  a  role  that  is  excluded,  he  can  put  this  agent  or 
the  role  in  the  Included  section. 


We  assume  that  agents  are  basic  entities  within  the  system  and  are  available  for  use 
in  role  definition. 
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4.  Defining  an  Authorization 

There  are  three  levels  of  authorization  for  a  message,  namely 

(1 )  message  type  level 

(2)  message  instance  level 

(3)  message  field  level 

If  an  authorization  Is  specified  at  the  message  type  level,  that  authorization  is  applied  to  all 
the  message  instances  of  that  message  type. 

There  are  five  access  rights  as  follows: 

(1)  read 

(2)  create  or  enter 

(3)  update 

(4)  discard 
(6)  mail 

Not  all  of  the  access  rights  listed  above  apply  to  a  particular  message.  For  example,  for  a 
message  field,  the  mail  access  right  does  not  make  any  sense  because  you  cannot  mail  a 
message  field  to  another  person.  Figure  4.1  is  a  list  of  all  the  authorizations  that  can  be 
applied  to  a  particular  system-supplied  form. 


I 

s)rstem- supplied  form 

access  rights 

message  type 

read 

create 

update 

discard 

mail 

message  instance 

read 

update 

discard 

mail 

message  field 

read 

enter 

update 

routing 

read 

create 

update 

discard 

constraints 

read 

create 

update 

discard 

authorization 

read 

update 

Rgure  4.1  Access  rights  allowed  for  a  system- supplied  form 
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4.2.: 


To  define  an  authorization,  the  user  needs  to  fill  out  the  form  shown  in  figure 


Authorization  :  _ 

Roles  Included  : . 
Roles  Excluded  : 


Figure  4.2  Syste no-supplied  form  tx>  define  an  authorization. 


When  defining  an  authorization,  there  is  no  section  for  agents  to  be  included  or 
excluded  because  roles  are  used  to  refer  to  a  particular  function.  In  this  way  we  eliminate 
the  need  to  change  the  authorization  specification  when  an  agent  changes  his/her  role  in  an 
office.  However,  if  an  agent  name  is  used,  the  CBDS  will  assume  that  the  specification 
means  the  agent  playing  the  role  of  himself.  This  is  used  to  handle  access  right  specification 
for  personal  messages  for  that  agent  so  that  every  agent  in  the  CBDS  can  have  their  own 
private  messages  regardless  of  the  roles  they  can  play. 

In  defining  an  authorization  for  a  message,  the  user  has  to  distinguish  between 
an  agent  that  can  play  a  role  and  an  agent  that  is  playing  a  role.  This  is  because  the  CBDS 
Interprets  the  specified  authorization  as  an  agent  that  can  play  a  role.  On  the  other  hand, 
playing  a  role  Is  used  to  identify  the  function  an  agent  is  to  carry  out.  The  next  section 
discusses  this  difference  in  greater  detail. 

5.  Role  Playing 

The  term  can  play  a  role  identifies  the  set  of  roles  in  which  an  agent  is 
included.  This  is  important  because  if  an  agent  can  play  a  particular  role,  then  he  has  access 
to  all  of  the  messages  for  which  the  role  is  included  in  an  authorization  form.  If  a  role  is  not 
specified  in  the  roles  included  section,  agents  that  can  play  that  role  are  not  allowed 
access  to  the  message  unless  a  generalized  role  of  this  role  is  specified.  To  exclude  an 
agent  from  having  access  to  a  message,  when  one  of  the  roles  that  an  agent  can  play  has 
access  to  it,  the  agent,  or  a  specialized  role  that  includes  the  agent,  must  appear  in  the 
roles  excluded  section  of  the  authorization  form. 

When  a  user  signs  on  to  the  CBDS,  the  system  will  identify  that  user  as  an 
agent.  Using  the  agent's  name,  all  the  corresponding  roles  that  the  agent  can  play  will  be 
Identified  at  that  time.  The  user  can  then  select  a  role  that  he  would  like  to  play.  This  selec¬ 
tion  is  not  binding  because  anytime  thereafter,  the  user  can  alter  the  role  he  is  playing. 
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The  concept  of  playing  a  role  is  used  so  that  the  user  can  structure  his/her 
work  according  to  functions  or  responsibilities.  (The  default  role  will  be  playing  the  role  of 
himself.)  For  example,  a  professor  may  be  both  a  faculty  member  of  the  Computer  Science 
Department  and  the  lab  manager  of  CSRG.  When  he  works  on  his  research,  he  may  not  want 
to  be  bothered  as  the  lab  manager  of  CSRG.  In  this  case,  when  he  signs  on  to  the  CBDS,  he 
plays  the  role  of  CSC  faculty  rriembcr  without  having  to  worry  about  the  work  he  has  to 
handle  as  the  lab  manager  of  CSRG.  Once  in  a  while,  he  will  have  to  deal  with  the  problems 
in  the  CSRG  lab;  he  then  can  play  the  role  of  lah  Tnanager  of  CSRG  and  handle  the  lab's 
work. 


If  an  agent  wants  to  have  access  to  the  messages  of  all  the  roles  he  can  play, 
he  will  have  to  play  the  most  specialized  role  he  can  play.  In  this  case,  he  has  access  to  all 
the  messages  at  that  level  as  well  as  the  messages  that  are  general  to  that  role.  For  exam¬ 
ple,  If  Joe  Smith  plays  the  role  of  Computer  Science  graduate  student,  he  will  at  the  same 
time  play  the  role  of  graduate  student  in  U  of  7  because  graduate  student  in  U  of  T\s  a 
generalized  role  of  Computer  Science  graduate  student.  In  this  case,  Joe  can  access  mes¬ 
sages  that  have  been  authorized  for  graduate  students  in  U  of  T  as  well  as  Computer  Sci¬ 
ence  graduate  students.  On  the  other  hand,  if  Joe  chooses  to  play  the  role  of  graduate  stu¬ 
dent  in  U  of  T,  then  he  can  only  access  messages  that  are  authorized  for  graduate  stu¬ 
dents  in  U  of  T.  To  access  messages  as  a  Computer  Science  graduate  student,  Joe  would 
have  to  play  the  role  Computer  Science  graduate  student  at  a  later  time. 

Therefore,  the  concept  of  playing  a  role  is  used  to  let  the  users  of  the  CBDS 
structure  their  work  by  playing  the  necessary  role,  and  the  concept  can  play  a  role  Is  used 
to  specify  the  exclusions  of  access  to  a  message. 


6.  Authorization  Levels 

As  mentioned  before,  authorization  can  be  specified  in  three  different  levels. 

They  are: 


(1 )  message  type  level 

(2)  message  instance  level 

(3)  message  field  level 

When  a  user  of  the  communication  base  wants  to  access  a  message  instance,  he  first  has  to 
identify  the  message  type.  Then  he  will  get  access  to  the  message  Instance  level.  After 
getting  into  the  message  instance  level,  he  can  fill  In  the  message  fields.  Hence,  the  authori¬ 
zation  specified  in  a  higher  level  takes  precedence  over  the  authorization  specified  in  a 
lower  level.  Thus  if  a  user  is  not  allowed  to  access  a  particular  message  type,  then  it  does 
rxDt  matter  whether  that  user  can  or  cannot  access  any  message  instances,  he  is  not 
allowed  to  get  into  the  message  instance  level  at  all. 
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7,  Default  Cases 

Authorization  can  be  specified  during  the  creation  of  a  message  ^  by  the  user 
creating  the  message.  Authorization  does  not  have  to  be  specified  for  all  the  messages.  If 
no  authorization  is  specified,  default  authorization  is  used  by  the  CBDS. 

The  default  authorization  for  a  message  type  (which  includes  all  the  message 
instances  for  the  message  type)  is  all  access  rights.  This  default  is  used  since  a  message 
type  is  the  highest  authorization  level  that  an  agent  has  to  pass  through  in  order  to  get  to 
the  message  instances  and  the  message  fields.  Most  of  the  time,  a  message  type  is  created 
by  the  CBA  to  let  the  CBUs  create  the  corresponding  message  instances.  Hence,  no  access 
right  restrictions  are  imposed  if  the  CBA  does  not  specify  an  authorization  for  the  message 
type. 


The  default  authorization  for  a  message  instance  is  the  same  as  the  authoriza¬ 
tion  for  the  corresponding  message  type.  Similarly,  the  default  authorization  for  a  message 
field  is  the  same  as  its  corresponding  message  instance  authorization. 

The  CBDS  also  allows  authorization  to  be  specified  for  an  authorization.  That  is, 
one  can  specified  which  users  are  allowed  to  change  the  access  rights  for  a  message.  Only 
the  person  who  created  the  message  Is  allowed  to  specify  who  can  change  the  access 
rights.  Hence,  there  is  no  default  In  this  case.  On  the  other  hand,  if  the  person  who  created 
the  message  does  not  specify  who  can  change  the  access  rights,  the  default  case  for 
accessing  the  authorization  system-sypplied  form  of  the  message  Is  that  it  is  only  accessi¬ 
ble  by  the  message  creator.  This  is  used  so  that  authorization  can  only  be  specified  by  the 
message  creator  unless  he  explicitly  grants  permission  to  some  other  person.  Hence,  the 
message  creator  plays  a  very  important  role  in  the  security  of  the  messages  he  creates. 


8.  Some  Exeimples 

In  order  to  give  some  examples,  let  us  assume  that  there  is  already  a  role  CSC 
defined,  which  consists  of  all  the  students  currently  playing  the  role  of  Computer  Science 
graduate  student.  The  following  is  a  list  of  those  students: 


alison 

ed 

carson 

John 

Chris 

oscar 

david 

pat 

murray 

Simon 

panes 

ken 

Assume  that  all  the  names  listed  on  the  left-hand  side  are  masters  students.  The  role 
master- CSC  can  be  defined  as  in  figure  8.1. 


In  this  context,  the  word  message  means  message  type,  message  instance  and  mes¬ 
sage  field. 
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Role  Name  :  master-CSC_ _ 

Agents  Included  :  _ _ 

Roles  Included  :  CSC  _ 

Agents  Excluded  :  ed, John, oscar, pat, sImon. 
Roles  Excluded  : _ 


Figure  8.1  Definition  of  the  role  Tr}.ast2T_CSC 


Similarly,  assume  that  all  the  agents  that  are  excluded  from  the  role  master- CSC  the 
role  PhD-  CSC.  This  role  then  can  be  defined  as  in  figure  8.2. 


Role  Name  :  PhD-CSC _ 

Agents  Included  : _ 

Roles  Included  :  CSC _ 

Agents  Excluded  : - 

Roles  Excluded  :  master-CSC 


Figure  8.2  Definition  of  the  role  PhD-  CSC 


Figure  8.1  and  Figure  8.2  have  illustrated  the  use  of  exclusions  in  defining  a 
new  role.  But  the  reader  should  realize  that  these  are  not  the  only  ways  that  these  two  new 
roles  can  be  defined.  One  also  can  list  out  all  the  agents  that  play  the  role  PhD-  CSC  to 
define  the  role  PhD-CSC.  Obviously,  as  the  number  of  agents  in  a  role  grows,  the  use  of 
exclusions  makes  specification  of  new  roles  a  lot  easier. 
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In  order  to  show  how  powerful  this  specificatbn  method  is,  let's  consider  a  more 
complicated  example.  Assume  that  the  following  agents  are  supervised  by  a  professor: 

alison 

carson 

david 

ed 

murray 

panos 

ken 

(i.e.,  the  above  students  play  the  role  of  student- of -professor).  This  role  can  be  defined  as 
in  figure  8.3. 


Role  Name  :  student-of-professor. 

Agents  Included  :  ed _ 

Roles  Included  :  CSC _ 

Agents  Excluded  :  chrls _ 

Roles  Excluded  :  PhD-CSC _ 


figure  8.3  Definition  of  the  role  student-of-professor 


The  above  definition  says  that  the  role  student-of-professor  is  played  by  all 
the  agents  in  the  role  CS’C  except  those  agents  that  can  play  the  role  PhD-CSC.  Agent  ed 
can  play  the  role  PhD- CSC,  but  he  is  also  supervised  by  the  professor.  Hence,  his  name 
appears  in  the  Included  section.  Similarly,  agent  chris  cannot  play  the  role  PhD-CSC, 
(remember  that  he  plays  the  role  CSC),  but  he  is  not  the  professor's  student.  Hence,  his 
name  appears  In  the  excluded  section. 

Rgure  8.3  is  only  used  to  illustrate  the  use  of  inclusions  and  exclusions.  The 
reader  should  realize  that  the  same  definition  can  be  simplified  if  the  role  master- CSC  \s 
used  instead  of  the  role  C5Cas  in  figure  8.4. 


Role  Name  :  student-of-professor. 

Agents  Included  :  ed _ 

Roles  Included  :  master-CSC _ 

Agents  Excluded  :  chris _ 

Roles  Excluded  : _ 


Figure  8.4  Allcmativc  dcfinilion  of  the  role  student-of-professor 


9.  Implementation 

Authorization  specification  requires  the  use  of  role  names.  In  order  to  use  role 
names,  they  have  to  be  defined  first.  To  define  a  role,  the  user  has  to  fill  out  the  form  in  fig¬ 
ure  3.1 .  During  the  compilation  of  this  form,  the  system  needs  to  check  for  the  following: 

(1 )  For  both  agents  and  roles,  the  same  name  should  not  appear  In  both  the  Inclusion 

and  exclusion  sections. 

(2)  A  role  In  the  exclusion  section  must  be  a  subset  of  one  of  the  roles  included. 

(3)  An  agent  in  the  exclusion  section  must  be  a  member  of  one  of  the  roles  included. 

(4)  An  update  to  this  form,  after  the  first  compilation,  should  not  allow  the  roles 

included  to  cause  a  loop  (i.e.,  no  contradiction  in  the  definition  of  the  roles 
included). 

Any  role  that  is  not  mentioned  is  excluded  (unless  there  is  no  authorization 
specified,  in  which  case  the  default  case  would  be  used).  Hence,  the  exclusion  section  is 
used  to  exclude  those  roles  that  are  already  included.  To  exclude  those  roles  that  are 
already  included  implies  that  the  role  must  be  a  subset  of  one  of  the  roles  in  the  included 
section.  Hence,  check  number  two  is  used  to  enforce  this  condition. 

Similarly,  check  number  three  is  used  for  agents. 

To  understand  the  need  for  check  number  four,  let  us  consider  the  following 
example.  Assume  that  there  are  two  roles,  R1  and  R2,  that  are  already  defined. 


Role  Name  :  R1 
Agents  Included  ;  a1  ,a2 
Roles  Included  :  R2 


Role  Name  :  R2 
Agents  Included :  a3,a4 
Roles  Included : 
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The  role  "R1"  contains  the  role  ’'R2"  as  a  sub-role  (i.e.,  in  role  "R1”  there  are  four  agents, 
namely,  a1,  a2,  a3  and  a4).  There  is  no  ambiguity  in  the  above  definition.  But  if  the  CBA 
wants  to  modify  the  definition  for  role  "R2"  and  put  role  "R1"  in  the  roles  included  section, 
then  there  will  be  a  loop. 


Role  Name  ;  R1 
Agents  Included  :  a1  ,a2 
Roles  Included :  R2 


Role  Name  :  R2 
Agents  Included  :  a3,a4 
Roles  Included :  R1 


When  the  CBDS  wants  to  Identify  the  agents  included  in  the  role  "R1”,  it  has  to  go  to  the 
Included  role  "R2"  to  find  out  who  is  in  ''R2".  Since  the  role  ”R1 "  is  included  in  the  role  "R2’', 
the  CBDS  has  to  go  to  the  role  "Rl"  again.  Hence,  we  have  an  infinite  loop.  This  is  only  a 
simple  example.  In  a  more  complicated  situation  more  than  two  roles  may  be  involved. 


It  Is  hard  to  detect  this  problem  during  run  time  because  the  CBDS  cannot  iden¬ 
tify  where  and  when  the  loop  starts  unless  It  keeps  track  of  all  the  roles  that  it  has  visited. 
A  more  effective  way  to  resolve  this  problem  is  to  detect  it  during  role  specification  and  not 
to  allow  the  CBA  to  store  a  role  if  there  is  a  loop.  In  the  specification  level,  It  is  easier  to 
detect  a  loop  because  the  CBA  can  only  modify  one  role  definition  at  a  time.  Therefore,  as 
long  as  the  role  being  modified  is  not  Included  in  any  of  the  subroles  that  it  includes,  there  is 
no  loop.  Hence,  check  number  four  is  used  to  prevent  this  problem  from  occurring  during  run 
time. 


A  newly  created  role  definition  would  not  have  this  problem  because  no  other 
roles  can  use  this  role  name  before  It  has  been  defined.  Once  this  role  is  defined,  another 
role  can  use  it  as  a  subset.  Hence,  a  loop  can  occur  only  when  a  role  definition  is  modified 
and  not  during  creation. 

After  compilation,  the  system  stores  the  system-supplied  form  for  a  role  defini¬ 
tion  by  linking  its  block  to  the  appropriate  place  in  the  role  network.  A  block  will  contain  one 
role  definition  and  pointers  to  agents  and  roles  included  and/or  excluded  (see  figure  9.1). 


Pointers  to 
Agents 
Included 

Pointers  to 
Roles 
Included 

Pointers  to 
Agents 
Excluded 

Pointers  to 
Roles 
Excluded 

l''igure  9.1  SirucUirc  of  an  aulhorr/.alion  block 


Hence,  a  simple  role  network  would  look  as  figure  9.2. 
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Fl^ure  9.2  A  simple  role  network. 


Figure  9.1  and  figure  9.2  are  only  a  logical  view  of  the  data  storage  representa¬ 
tion.  Physically,  the  information  is  stored  in  the  data  base.  Five  relations  are  used  to  store 
this  information.  They  are: 

rolGLjlef  (  role,  Al/^,  R\^,  AEj^,  ) 

ALdef  (  ALid,  A1  ) 

RL_def(  RLdd,R^  ) 

AE_def  (  AEJd,  A2  ) 

RELdef  (  RKjid,  R2  ) 

The  foltowing  table  explains  the  meaning  of  the  attribute  names. 


attribute  name 

meaning 

role 

the  role  name 

Al 

agents  included 

Rl 

roles  included 

AE 

agents  excluded 

RE 

roles  excluded 

Al,  A2 

name  for  an  agent 

Rl,  R2 

name  for  a  role 

figure  9.3  Meaning  of  attributes  used  in  role  definition 
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To  check  for  loops  during  modification  to  the  role  definition,  the  CBDS  uses  the 
roles  included  to  find  their  corresponding  blocks.  Then  it  uses  these  blocks  to  find  the  roles 
that  they  point  to.  If  one  of  the  role  names  that  a  block  points  to  is  the  same  as  the  role 
name  that  Is  being  modified,  then  there  is  a  loop.  This  process  continues  until  no  more 
pointers  can  be  found  or  a  role  name  Indicated  in  the  roles  excluded  section  is  the  same  as 
the  role  name  that  is  being  modified.  The  algorithm  betow  describes  this  checking  in  detail. 


RI_xoles(*)  and  RE_Foles(*)  are  the  modified  versions  of  roles  Included  and  roles  excluded. 


1=1; 

status  =  OKAY; 

while  (  RI_ioles(i)  not  empty  AND  status  =  OKAY  )  do 
begin 

status  =  traverse_down  (  RIjcolesCi),  RE_roles(’^),  RI_ioles(i)  ); 
1  =  1+  1 ; 
end; 

<<<  status  at  this  time  will  indicates  whether  there  is  a  loop  >>> 

procedure  traverse_down  (  rolejame,  exclusions(*),  orlginal_role  ); 
begin 

roleJncludedC*)  <-  select  R1  from  role_def,  Rl_xlef  where 

Rl/^  =  RIJ.d  AND  role  =  role_name; 
if  roleJncludedC*)  is  empty  then  returnCOKAY); 

for  each  roleJ[ncluded(j)  do 

if  roleJncludedCj)  =  originaLrole 
then  retum(LOOP); 

role_excluded(’^)  <-  select  R2  from  role_def ,  RE_xief  where 

RE^  =  RE_Ld  AND  role  =  role_name; 

for  each  roleJlnclude(j)  not  in  exclusions(*)  do 
begin 

result  =  traverse_down  (  role_includedCj), 

role_excluded(*)  +  exclusions(’^), 
originaljcole  ); 

if  result  =  LOOP  then  retumCLOOP); 
end; 

retumlOKAY); 

end; 


To  identify  the  roles  a  user  can  play,  the  system  has  to  find  the  block  that  has 
his  name  In  the  agents  included  section.  Using  the  role  name  of  this  block,  the  system  then 
finds  out  all  the  blocks  that  point  to  this  block  (i.e.,  the  roles  that  have  this  role  as  a  sub¬ 
set).  Then  it  uses  these  roles  to  find  the  blocks  that  point  to  these  other  roles.  This  search¬ 
ing  continues  until  either  no  more  pointers  can  be  found  (i.e.,  the  root  of  the  tree  has  been 
found),  or  the  role  name  appears  in  the  roles  excluded  section.  The  algorithm  below 
describes  this  searching  for  the  roles  a  user  can  play.  The  roles  that  a  user  can  play  are 
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stored  in  the  variable  called  "roles_play”. 


AE_roles(*)  <-  select  role  from  role_def,  AE_iJef  where 
AE^  =  AE_Ld  and  A2  =  <user>; 

AI_roles(’')  <-  select  role  from  role_def,  Al_def  where 
Al/j/  =  Al_id  andAI  =  <user>; 
roles_play(*)  <-  Al_roles(*); 

for  each  AI_roles(i)  do 

traverse_iip  (AI_roles(i),  AE_roles(*)); 

procedure  traverse_up  (role_name,  exclusions(*)); 
begin 

RI_roles(*)  <-  select  role  from  role_def,  Rl_def  where 
RI/5*  =  Rl_id  and  R1  =  role_name; 
if  RI_roles(*)  is  empty  then  return; 
append  those  RI_roles(j)  not  in  exclusionsC"^)  to 
roIes_play(’'); 

RE_roles(*)  <-  select  role  from  roIe_def,  RE_def  where 
RE^  =  REJ.d  and  R2  =  role_riame; 
for  each  RI_roles(k)  not  in  exclusions(*)  do 

traverse_up  (RI_ioles(k),  RE_roles(*)  +  exclusions(*)); 

end; 


After  all  these  roles  have  been  identified,  the  user  can  then  select  a  role  that  he 
wants  to  play.  If  a  user  selects  a  role,  then  all  the  roles  that  have  this  role  as  a  subrole  must 
be  found.  This  is  because  the  user  also  plays  those  roles. 

To  understand  this  role  playing  more  clearly,  let  us  consider  an  example.  Assume 
"CSRG  student"  is  a  subrole  of  "grad  student".  Then  when  one  plays  the  role  of  a  "CSRG 
stud(3nt",  one  also  at  the  same  time,  plays  the  role  of  a  "grad  student".  But  the  converse, 
that  one  who  plays  the  role  of  "grad  student"  is  necessarily  a  "CSRG  student",  is  not  true. 
The  algorithm  to  find  equivalent  roles  is  the  same  as  the  algorithm  that  finds  the  roles  a  user 
can  play.  However,  the  results  are  stored  in  the  variable  name  "playingC*)". 

There  is  an  interesting  result  here.  Since  relations  are  used  to  store  the  defini¬ 
tion  of  roles,  the  transformation  "join"  can  be  used  to  retrieve  those  roles  that  have  a  par¬ 
ticular  role  as  a  subrole  as  well  as  what  roles  are  contained  in  a  particular  role.  If  a  data 
base  management  system  is  not  used,  then  each  block  (as  described  In  figure  9.1)  will  have 
to  have  two  pointers  for  roles  included  and  roles  excluded  (i.e.,  one  is  used  to  point  to  roles 
that  are  included  in  this  role  as  a  subrole,  the  other  one  is  used  to  point  back  to  those  roles 
that  include  this  role  as  a  subrole). 

To  define  an  authorization,  the  user  has  to  fill  out  the  form  in  figure  4.2.  Note 
that  the  exclusions  can  only  be  role  names.  If  an  agent  name  is  listed,  it  can  only  appear  in 
the  "Inclusions".  This  implies  that  the  agent  is  playing  the  role  of  himself. 
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During  the  compilation  of  an  authorization  system-supplied  form,  the  system 
needs  to  check  the  following: 

(1)  The  same  role  name  should  not  appear  in  both  the  inclusion  and  exclusion  sec¬ 

tions. 

(2)  A  role  In  the  exclusions  must  be  a  subset  of  one  of  the  roles  included. 

As  In  defining  a  role,  the  information  about  an  authorization  is  stored  in  the  data 
base.  Three  relations  are  needed  to  store  this  Information. 


auth.(  num,  authJ.ype,  include,  exclude  ) 

inclusions  (  in^,  in_name  ) 
exclusions  (  out§,  ou1_name  ) 


Figure  9.4  explains  the  meaning  of  each  attribute: 


attribute  name 

meaning  or  values 

num 

a  unique  key  to  identify  the 
system-supplied  form  that  needs 
this  authorization  specification 

auth_type 

type  of  access  rights 
(e.g.,  read,  update,  ship,  etc.) 

iruname 

name  of  a  role  that  is  included 

out_rame 

name  of  a  role  that  is  excluded 

include,  ir\^ 

include  is  a  pointer  to  \r\§ 

exclude,  ouXS 

exclude  is  a  pointer  to  out^ 

Figure  9.4  Meaning  of  attributes  in  authorization  relations 


The  above  three  relations  are  shown  in  a  general  form.  In  the  actual  implementa¬ 
tion,  one  of  these  sets  of  relations  is  used  for  each  system-supplied  form  that  can  have  an 
authorization  specified  for  it.  For  example,  the  three  relations  that  are  used  to  store  the 
authorization  for  message  types  are  as  follows: 


raL_auth  (  mt_jiurri,  mtujuthUtype ,  mUnclude,  mt_exclude  ) 

niLJnclusions  (  Tn.tJ,nff,  mUnjiame  ) 
mtjDXclusions  (  mt^outff,  mt_£)ut_name  ) 


As  the  reader  might  have  already  realized,  the  difference  between  this  set  of  relations  and 
the  general  form  Is  that  this  set  of  relations  has  all  relation  names  and  attribute  names  pre¬ 
ceded  with  three  characters  "mt_I'.  (The  mt  stands  for  message  type.)  Also  in  this  case,  the 


variable  "mt_num"  would  contain  a  unique  key  to  identify  a  particular  message  type.  Simi- 
lariy,  "mi”  would  mean  message  instance,  ”mf”  would  mean  message  field  and  so  on.  A  full 
listing  of  all  the  relations  used  for  the  authorization  implementation  can  be  found  in  appendix 
II. 


All  default  cases  would  have  no  entry  in  the  relation.  In  this  way  the  CBDS  can 
identify  the  default  cases  if  nothing  is  returned  from  a  retrieval  statement.  It  also  saves 
storage  when  the  user  uses  the  default  case. 

It  is  mentioned  before  that  after  a  user  selects  a  role  to  play,  all  the 
corresponding  roles  that  have  this  role  as  a  subrole  would  be  found  and  stored  in  the  vari¬ 
able  named  ”playing(*)''.  Hence,  an  authorization  for  a  message  would  be  granted  if  no  role 
In  the  "roles  excluded"  section  is  the  same  as  any  one  of  the  playingC*)  '  and  one  role  in  the 
"roles  included"  section  is  the  same  as  one  of  the  playingC*). 

The  following  steps  describe  how  the  CBDS  checks  for  the  authorization  when  a 
CBU  P  wants  to  obtain  access  to  a  message  type  T. 


auth_table(MESSAGEJrYPE,*)  <-  OK; 

resuItC*)  <-  select  unique  mt_auth_type  fronimt_auth; 

for  each  result(i)  do 
begin 

auth_lable(MESSAGE_JYPE,result(i))  <-  NO; 

in_role(*)  <-  select  mt_in_na me  from  mt_auth,  mtJnclusions  where 
mt_num  =  T  and 
mt_auth_type  =  result(i)  and 
mt_include  =  mt_in/(|!; 

outjfoleC*)  <-  select  mt_Dut_jname  frommt_auth,  mt_exclusions  where 
mt_Dum  =  T  and 
mt_auth_lype  =  result(i)  and 
mt_exclude  =  mt_Dut^; 
if  one  of  out_role(j)  is  in  playing(’") 

then  auth_table(MESSAGE_JYPE,result(j))  <-  NO; 
else  if  one  of  in_iole(j)  is  in  playingC*) 

then  auth_table(MESSAGE_rYPE,result(j))  <-  OK; 

end; 


The  variable  named  ”auth_table",  mentioned  in  the  algorithm,  is  a  table  which  contains  the 
information  shown  in  figure  9.6. 


t  This  is  because  "can  play  role"  is  applied  in  authorization  specification  as  described  in 
section  6. 
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read 

enter/create 

update 

discard 

mail 

MESSAGE  TYPE 

MESSAGE  INSTANCE 

MESSAGE  FIELD 

flgure  9.5  The  "auth_lable"  table 


The  reader  should  note  that  if  result(*)  is  empty  after  execution  of  the  second  statement, 
then  the  program  does  not  go  into  the  loop.  In  this  case,  all  access  to  a  message  type  is 
allowed  (i.e.,  the  default  authorization  for  message  types  is  used). 

Since  during  access  to  a  message,  the  user  needs  to  first  go  through  the  mes¬ 
sage  type  level  and  the  message  instance  level  before  he  can  get  into  the  message  fieid 
level.  Information  about  the  three  levels  has  to  be  kept.  In  this  case,  if  there  is  no  authoriza¬ 
tion  specified  at  the  message  instance  level  or  the  message  field  level,  then  the  authoriza¬ 
tion  specified  for  the  level  above  It  would  be  used. 

To  gain  access  to  the  message  instance  and  message  field,  the  algorithm  used  is 
similar  to  the  one  described  above. 

The  algorithms  described  above  on  authorization  have  been  implemented  and  run 
under  the  UNIX  operating  system  [ThRi78].  The  programs  are  written  in  the  C  programming 
languague  [KeRi78]  and  run  on  top  of  the  MISTRESS  data  base  management  system 
[Rhod81  ]. 

10.  Conlusion 

Introducing  the  idea  that  a  user  can  play  certain  roles,  authorization  has  been 
specified  using  these  roles.  Also,  allowing  a  role  to  contain  other  roles  simplifies  the  specifi¬ 
cation  of  authorization  for  the  user.  Unfortunately,  this  Introduces  new  problems,  like  looping 
In  the  definition  of  roles,  which  needs  to  be  detected  before  the  definition  can  be  stored. 
Algorithms  for  enforcing  authorization  have  been  proposed  and  Implemented. 

Throughout  the  design  and  implementation  of  the  CBDS,  we  assumed  that  the 
CBDS  only  runs  in  one  workstation.  This  means  that  all  the  data  is  stored  In  one  data  base 
only.  Hence,  mailing  is  not  supported  in  this  design  of  a  CBDS  [Woo  83].  Authorization  can 
be  specified  and  enforced  for  a  particular  message  instance.  However,  if  this  message 
instance  is  mailed  to  someone  else,  would  the  same  authorization  still  apply?  What  happens 
if  the  authorization  of  this  message  instance  is  only  allowed  to  be  accessed  by  the  message 
creator?  In  routing  specification  [Maze83],  will  the  authorization  follow  the  message 
instance  wherever  It  goes?  What  happens  If  the  sender  mails  a  message  instance  to  some¬ 
one  who  is  not  allowed  to  access  that  message  instance?  Is  It  possible  that  a  message 
instance  would  be  lost  because  of  improper  authorization  specification  and  improper  mailing? 
All  these  problems  might  not  be  difficult,  but  they  have  to  be  solved  before  the  MMS  can  be 
used. 
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Abstract 

A  message  management  system  is  a  system  for  managing  structured  messages, 
integrating  the  facilities  of  computer-based  message  systems  and  database  management  sys¬ 
tems.  €Uid  adding  to  them  the  capability  of  "intelligent”  messages.  "Intelligent”  messages 
are  messaiges  that  can  use  information  about  themselves,  such  as  structure  and  content,  or 
about  the  system  to  effect  their  own  processing. 

An  important  aspect  of  providing  messages  with  "intelligence”  is  the  ability  to 
specify  the  logical  routing  of  a  message.  This  paper  introduces  a  framework  and  language  for 
the  specification  of  routing  for  messages  in  a  message  management  system.  By  associating 
routing  specifications  with  message  types,  the  system  assumes  the  responsibility  both  for 
evaluating  the  current  message  instance  state  to  yield  the  next  destination  for  the  instance 
and  for  forwarding  the  instance.  The  user  is  freed  from  the  need  to  explicitly  direct  each 
instance  of  a  message  type.  Not  all  message  types  will  have  prespecifiable  routings.  The 
routing  specifications  are  based  on  a  variety  of  criteria,  including  system  characteristics  and 
message  instance  state,  among  others.  A  routing  specification  language  is  outlined. 


t  An  earlier  version  of  this  paper,  by  Murray  S.  Mazer  and  Frederick  H.  Lochovsky,  appeared 
in  Proc,  Suftemth  Hoavaii  bitemalioncd  Cbri/ervTwe  on  System  Stiences,  Honolulu,  5-7  Janu¬ 
ary  10B3,  Vol.  1,  pp.  56©- 575. 
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1.  rNTRODUCl'lON 

Much  ofTort,  has  been  devoted  recently  to  the  application  of  computer  technologies  and 
techniques  in  the  office  environment.  The  current  trend  is  toward  a  gradual  integration  of 
automation  into  every  aspect  of  the  office  infrastructure  [Pajrsn82].  Office  information  sys¬ 
tems  should  take  over  the  repetitious  and  routine  tasks  which  people  traditionally  do  not 
enjoy,  while  at  the  same  time  providing  a  set  of  tools  for  the  unstructured  functions  which 
require  human  expertise  and  direction.  The  advent  of  office  information  systems  is  bringing 
about  the  integration  of  two  established  technologies  —  computer-based  message  systems 
and  database  management  systems.  The  facilities  of  both  technologies  need  to  be  provided, 
in  an  integrated  manner,  in  office  infornf'ation  systems.  However,  this  integration  in  itself  is 
not  adequate  for  many  office  systems  applications.  Whereas  computer-based  messEige  sys¬ 
tems  and  database  management  systems  are  usually  passive,  in  that  the  users  have  to  ini¬ 
tiate  all  actions  in  the  system,  office  systems  require  that  the  computer  take  an  increasingly 
active  role  in  controlling  and  co-ordinating  information  flow  [TsichBO]. 

A  message  maTiagement  system.  (MMS)  is  conceptually  an  integration  of  computer-based 
message  systems  and  database  management  systems  [Tsich02a,  TsichBl,  MartiB2c],  A  MMS  is 
typically  manifested  over  a  distributed  system  of  autonomous  workstations.  The  MMS  not 
only  delivers  messages  (as  does  a  computer-based  message  system),  but  edso  manages  them 
(ais  does  a  database  management  system).  Database  management  systems  typically  meinipu- 
late  the  contents  of  structured  data  efficiently,  but  do  not  handle  well  unstructured  data, 
such  ais  audio,  text,  and  video.  Computer-based  message  systems  tremsmit  both  structured 
and  unstructured  messages  but  do  not  manipulate  the  contents  of  the  messages.  Recent 
extensions  to  database  management  systems  to  handle  unstructured  data  facilitate  the 
integration  sought  in  message  management  systems  [FalouB2,  EconoB2,  StoneB2]. 

Messages  in  a  MMS  are  structurally  typed.  Instances  of  message  types  are  stored  in  a 
communication  base,  which  is  the  cumulative  information  repository  of  the  MMS  and  the 
medium  by  which  users  communicate  with  each  other.  A  communication  base  administrator 
(CBA,  analogous  to  a  database  administrator  [Kroen77])  is  responsible  for  the  creation, 
maintenance,  security,  and  integrity  of  the  communication  base  [Woo83].  The  structure  of 
the  message  type  is  used  by  the  system  to  enable  manipulation  of  the  contents,  location,  and 
routing  of  messages  [Marti62a]. 

A  logical  routing  technique  in  a  message  system  specifies  the  logical  path(s)  to  be  taken 
by  a  message.  This  kind  of  routing  differs  from  that  in  computer  networks,  where  the  con¬ 
cern  is  determining  a  physical  path  for  messages  between  any  pair  of  source  and  destination 
nodes  in  the  network^  [ShochTB,  McQui??]. 

Routing  specification  techniques  in  computer-based  message  systems  have  t3p>ically 
taken  a  narrow  view  of  logical  message  travel  within  a  system.  Specifications  are  typically 
from  a  given  user  only  to  the  most  immediate  destination,  and  each  user  must  explicitly 
direct  each  message  as  it  flows  around  the  system.  While  some  messages  in  a  message  sys¬ 
tem  do  travel  only  from  one  user  to  another  and  then  stop,  messages  in  general  travel 
around  the  system  on  a  tour  of  some  subset  of  the  system’s  users.  A  logical  routing  system 
should  support  such  a  general  approach  to  message  travel.  A  MMS  routing  framework  should 
reflect  this  more  globed  attitude  toward  message  flow. 


j  'Pjg  notion  of  messo^es  is  ambiguous  here.  When  referring  '-o  computer  networks,  a  message  is  the  basic  physical 
unit  of  data  transfer,  including  format  and  protocol  information.  It  may  or  may  not  (most  likely  not)  embody  a  full 
logical  message  from  the  source  user  to  the  destination  user.  When  referring  to  a  message  system,  a  message  is  the 
basic  logical  unit  of  information  exchange  between  users.  To  effect  transfer  of  a  logical  message  between  users,  the 
brcaks  the  logiceil  message  into  several  physical  messages  that  are  sent  across  some  network  and 

reassembled  at  the  destination. 
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The  routing  of  messages  in  a  MMS  specifies  the  logical  paths  to  be  taken  by  a  message 
instance  in.  order  to  effect  some  processing  goals  of  the  system.^  A  MMS  routing  specifies  the 
logical  movement  of  message  instances  among  some  set  of  users  according  to  predefined  cri¬ 
teria.  The  routing  may  be  dynamic,  depending  upon  both  system  state  and  message  instance 
state.  By  allowing  routing  specifications,  the  system  frees  the  user  from  the  need  to  direct 
explicitly  each  message  instance  on  its  lour  of  the  system. 

While  the  need  for  research  into  the  specification  of  routings  in  message  management 
s)^tems  has  been  recognized  [Ellis82,  GehanBS,  TsichBl,  EllisBO],  little  work  has  considered 
the  topic.  Logical  routing  techiniques  have  remained  stable  throughout  most  of  the  develop¬ 
ment  of  electronic  message  systems,  until  recently.  In  a  typical  electronic  message  system, 
the  user  would  explicitly  specify  the  destinations  for  every  message  instance  s/he  sends. 
The  destination  would  be  single-hop;  the  user  specifies  the  single  most  immediate  destina¬ 
tion,  from  which  the  next  user  must  specify  the  next  destination,  and  so  on.  Distribution 
lists  could  also  be  specified  to  send  a  copy  of  the  original  instance  to  each  member  of  some 
set  of  users. 

Some  recent  systems  allow  implicit  destination  specification,  which  frees  the  user  from 
explicitly  specifying  each  destination  for  each  instance  sent.  In  the  prototype  systems  of 
[ShuBl]  and  [TsichBSa,  TsichBSb],  an  automatic  routing  facility  is  provided,  for  example,  by 
the  specification  of  destination  pseudosketches  for  automatic  procedures  [HoggB3a].  Pro¬ 
cedures  are  specified  at  stations  for  actions  to  be  triggered  by  the  arrival  of  certain  types  of 
messages.  These  actions  can  include  dynamically  forwarding  the  messages  to  another  sta¬ 
tion.  The  emphasis  is  on  specifying  for  each  station  how  different  types  of  messages  are  to 
be  handled.  '^Attal,  in  his  experimental  system  for  active  messages,  aUowed  simple  routing 
("message  circulation")  specifications  by  the  inclusion  as  part  of  the  message  of  an  ad  hoc 
serial  distribution  list  [YittaBl].  This  capability  is  very  limited,  allowing  a  simple 
specification  technique  and  no  decision  criteria.  Chang  and  Chang  use  database  alerting 
techniques  for  office  activities  management,  and  routing  specifications  are  formed  as 
actions  in  alerts  [ChangBS].  'Fhe  routing  is  specified  by  conditions  formulated  in  terms  of 
changes  to  the  database  state.  In  the  Office  Procedures  by  Example  (OBE)  system,  a  sophisti¬ 
cated  technique  using  examples  allows  the  specification  of  either  static  or  dynamic  distribu¬ 
tion  lists  for  business  objects  [ZloofBl].  The  distribution  list  for  an  object  only  applies  from 
one  user  to  the  destination  user;  the  routing  is  only  one-hop  for  an  object.  The  Grapevine 
multicomputer  system  on  the  Xerox  research  internet  provides  facilities  for  the  delivery  of 
digital  messages  with  primary  emphasis  on  computer  mail  [BirreBS].  The  set  of  destinations 
for  a  message  is  recui'sively  enumerated  from  a  list  of  recipient  names  (each  of  which  may 
be  a  list),  and  each  destination  receives  a  separate  copy  of  the  messege.  .No  shared  access  to 
a  single  copy  of  the  message  is  implied.  The  routing  is  single-hop,  and  no  support  is  given  for 
conditional  routing. 

In  this  paper,  we  present  a  framework  for  routing  specifications  in  a  MMS.  Different 
kinds  of  routing  specifications  are  identified.  Routing  specification  constituents  and  criteria 
are  discussed.  After  examining  routing  evaluation  and  distribution,  we  outline  a  routing 
specification  language. 

2.  A  ROUTING  SPEOFICATION  FRAMEWORK 

Our  framework  for  routing  specifications  has  a  different  emphasis  from  those  outlined 
above.  The  routings  specify  the  next  destinations  for  each  message  type  according  to 
current  message  and  system  state.  The  specification  covers  the  full  tour  of  the  instance  in 
the  MMS.  The  emphasis  is  on  messages  as  independent,  "intelligent"  entities  guiding  them¬ 
selves  through  the  system,  not  on  stations  directing  messages  as  they  flow  through  each  sta¬ 
tion. 


2  The  proceasiag  of  message  instances  is  distinct  from  the  routing  of  the  instances.  A  user  processes  the  instance 
body,  by  reading  and  modif3hiig  its  contents,  and  tiien  the  message  is  sent  to  the  next  user. 
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A  routing  specification  for  a  message  type  is  a  basic  property  of  that  type.  Two  message 
types  that  differ  only  in  their  routing  specidcations  but  are  otherwise  equivalent  are  con¬ 
sidered  as  two  separate  types.  This  becomes  important  in  handling  copies  of  messages  (see 
Section  2.3).  Note  that,  in  general,  not  all  message  types  will  have  prespecifiable  routings. 

2.1.  Kinds  of  Routing  Specifications 

There  are  two  kinds  of  routing  specifications  for  normal  situations: 

a)  Tifpe  Routing 

The  routing  is  specified  by  the  CBA  at  message  type  creation  time.  In  this  case,  the 
routing  specification  is  part  of  the  type  specification  for  the  message  t3q>e.  The 
routing  specification  applies  in  general  to  all  instances  of  the  message  type, 
excluding  those  instances  subject  to  either  instance  routing  or  override  routing 
(see  below). 

b)  fnstance  Routing 

The  routing  is  specified  by  the  user  at  message  instance  creation  time,  end  the 
specification  applies  to  the  present  message  instance  only. 

There  is  also  a  routing  for  exceptional  situations  known  as  override  routing.  In  excep¬ 
tional  cases,  the  normal  routing  specification  (either  type  or  instance)  must  be  suspended 
and  replaced  with  either  an  ad  hoc  specification  or  m.ai.iua).  routing.^  Note  that  this  may  take 
place  while  the  instances  are  already  circulating  somewhere  in  the  system.  Override  routing 
can  be  specified  at  both  the  type  and  instance  levels.  At  the  type  level,  override  routing  can 
be  used  to  effect  the  forwarding  of  all  message  instances  of  one  type  temporarily  from  one 
site  to  an  equivalent  site.  For  example,  when  a  certadn  user  is  absent  from  the  system  for  an 
extended  period,  messages  destined  for  that  user  might  be  rerouted  (forwarded)  to  another 
user,  as  specified  for  each  message  type,  for  action.  At  the  instance  level,  override  routing 
can  be  used  to  suspend  the  routing  for  a  certain  message  instance  and  to  either  specify  a 
new  automatic  routing  for  the  instance  or  route  it  manually.  For  example,  when  the  pro¬ 
cessing  of  an  order  must  be  expedited,  override  instance  routing  can  be  used  to  effect  such 
processing  for  this  instance  only.  Instance  level  override  routing  is  also  useful  for  handling 
routing  specification  errors  detected  at  run  time. 

Support  for  override  routing  implies  an  ability  to  suspend  the  normal  routing  for  mes¬ 
sage  types  at  some  or  all  locations  in  the  MMS.  In  addition,  one  may  wish  to  display  the 
current  routing  specifications  and  to  edit  them  to  effect  a  temporary  routing  specification. 
This  includes  the  editing  of  not  only  where  the  message  goes  but  also  the  decision  criteria 
used.  As  well,  it  must  be  possible  to  know  an  instance’s  current  location  in  the  system  and 
the  path  taken  to  get  there  (i.e.,  to  provide  "some  information  about  the  communication 
history  of  a  message"  [Marti82b]).  In  general,  if  one  edits  a  type  routing,  the  corresponding 
message  type  is  changed.  Editing  for  override  routing,  however,  does  not  change  the  mes¬ 
sage  type,  only  its  routing  specification.  In  this  case,  the  original  routing  specification  is 
retained  and  can  be  restored  at  any  time.  In  the  former  case,  the  original  routing 
specification  is  lost. 

An  authorization  mechanism  is  required  to  determine  who  can  specify  each  of  the  three 
types  of  routing.  For  example,  the  CBA  will  normally  specify  the  type  routing  when  the  mes¬ 
sage  type  is  created;  no  other  user  would  be  allowed  to  do  so.  Instance  routing  would  be 
specified  by  the  user  creating  the  instance,  Authorization  for  override  routing  could  go  to, 

3  kfLTiiifl]  rouUn^,  whicii  b  soixt'cc  user  explicitly  directs  the  messB^e  to  hs  most  imixiediBte  destmAtioxi,  is  the 
standard  kind  of  routing  found  in  most  message  systems.  Manual  routing  is  not  one  of  the  kinds  of  routing 
specifications  identified  in  this  section,  because  manual  routing  falls  outside  our  framework.  In  manual  routing,  the 
burden  of  directing  messages  is  placed  with  the  user,  and  messages  travel  in  a  single-hop  fashion.  Manual  routing 
must  be  supported  by  a  MMS  to  provide  sufficient  flexibility  in  message  sending.  All  messages  for  which  routings  are 
not  specified  within  our  framework  must  be  sent  by  manual  routing. 
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for  example,  the  CBA,  the  originating  user,  some  specially  designated  set  of  users,  or  any 
user.  Default  authorizations  would  be  used  in  cases  where  explicit  authorization  is  not 
given. 

2.2.  Rouiiiig  ^reification  Constituents  and  Criteria 

A  routing  specification  consists  of  n  .s-i/es  (n>l)  tlirough  which  the  instances  of  a  mes¬ 
sage  type  may  travel.  In  contrast,  a  message  instance’s  actual  routing  consists  of  s  sites 
through  which  the  instance  does  travel,  from  the  origin  site  0  to  the  final  destination  site  D. 
Note  that  the  s  sites  through  which  the  instance  travels  are  not  necessarily  unique;  they  are, 
however,  selected  from  the  n  potential  sites.  For  a  given  message  type,  s  is  not  necessarily  a 
constant  across  all  instances,  due  to  the  functional  evaluation  of  the  routing  according  to 
the  criteria  discussed  below.  A  routing  may  have  a  set  of  possible  origins  (according  to  the 
message  creation  authorizations)  and  a  set  of  possible  destinations.  Any  instance  will  have 
only  one  origin  and  one  final  destination  (perhaps  a  concurrent  one  (see  Section  2.3)). 

For  each  site,  a  routing  specification  consists  of  a  set  of  optional  decision  criteria  and  a 
set  of  destinations  (next  sites).  A  message  routing  has  as  sites  roles,  which  correspond  to 
individuals,  functions,  or  system  servers  within  some  infrastructure  [Marti82a,b,c].  For 
example,  manager,  secretary,  project  member,  and  John  Smith  may  be  roles  in  an  orgeuiiza- 
tion.  Examples  of  system  servers  are  printers,  bulletin  boards,  file  cabinets,  archival 
storage,  data  bases,  and  garbage  cans.  Roles  do  not  necessarily  map  directly  to  physical 
workstations.  There  may  be  one  or  several  roles  on  any  individual  workstation.  The  role  to 
workstation  binding  can  occur  when  a  user  signs  on  to  the  system. 

Recall  that  a  routing  specifies  the  logical  paths  to  be  taken  by  a  message  instance  on  its 
Lour  of  the  system.  The  routing  is  therefore  specified  in  terms  of  the  logical  processing  enti¬ 
ties,  the  roles,  through  which  messages  pass.  These  logical  sites  must  then  be  mapped  to 
logical  address  ids  and  then  to  mail  slots  (physical  addresses)  as  described  in  [Marti62c]. 

Tsichritzis  discusses  the  notions  of  a  mail  address  and  a  routing  address  [TsichB2c]. 
Routing  addresses  only  forward  messages  to  other  addresses;  they  never  create  or  keep  (pro¬ 
cess)  messages.  Addresses  where  messages  can.  originate  or  be  deposited  as  well  as  be  for¬ 
warded  are  called  mail  addresses.  The  routing  system,  proposed,  here  does  not  differentiate 
between  the  two  typ)es  of  addresses  (or  sites,  in  our  terminology),  because  the  routing  sys¬ 
tem  is  concerned  with  evaluating  the  instance  after  the  instance  is  processed  by  the  site. 
Therefore,  whether  the  site  actually  processes  the  instemce  (as  in  a  mail  address)  or  not  (as 
in.  a  routing  address)  is  irrelevant  to  the  routing  system  (see  Section  3.2,  Example  6). 

A  routing  may  be  unconditional,  or  it  may  be  conditional  and  dependent  upon  veu'ious 
criteria,  such  as; 

a)  values  of  fields  in  the  message  instance. 

b)  system  characteristics  (such  as  current  load  at  a  site). 

c)  the  number  of  times  the  instance  has  passed  through  the  site  previously. 

d)  the  origin,  current,  or  previous  site  of  the  instance  in  the  system. 

e)  time  constraints  on  instance  processing.  A  duration  may  be  specified  as  the 
minimum  (and  maximum)  time  an  instance  is  to  remain  at  its  current  site  (e.g.,  a 
message  posted  at  a  bulletin  board).  A  time  Limit  may  be  specified  as  the  maximum 
time  by  which,  an  instance  must  be  fully  processed;  beyond  this  time, 

i)  an  alert  message  could  be  sent  to  some  sites  (e.g.,  the  role  and/or  the  role’s 
supervisor),  and 

ii)  the  message  could  automatically  be  rerouted  (i.e.,  taken  away  and  sent  to 
another  site). 

A  routing  may  be  specified  only  for  an  original  message  instance.  Copies  of  a  message 
may  be  generated  at  a  site  (perhaps  by  an  automatic  procedure  or  by  an  explicit  user 
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directive),  but  these  copies  are  treated  as  independent  instances  of  a  different  message  type, 
with  their  own  routing  specifications.  Recall  that  two  message  types  differing  only  in  the 
routing  specifications  m  e  two  different  messtige  types.  The  copies  generated  at  a  site  will  be 
instances  of  a  different  message  type  whose  origin  is  the  current  site  and  whose  body  is 
exactly  the  same  in  definition  as  the  current  type,'^  but  whose  routing  specification  differs 
from  that  of  the  current  type.  The  original  contents  of  the  new  instances  will  be  exactly  the 
same  as  the  contents  of  the  current  instance.  A  common  framework  is  therefore  preserved 
across  originals  and  copies;  no  special  treatment  (and  the  accompanying  complexity)  need 
be  given  to  copies.  As  well,  this  ^lows  the  user  to  decompose  the  routing  specifications  and 
to  separate  the  original  instance’s  routing  from  the  copy  routing, 

2.3.  Sequential  versus  Concurrent  (Parallel)  Routing 

The  sender  of  a  message  Instance  may  wish  to  send  the  instance  either  sequentiedly,  in  a 
well-determined  order,  to  a  list  of  recipients,  or  concurrently  to  the  list.  In  the  latter  case, 
the  instance  is  sent  to  all  the  recipients  at  the  same  time.  This  can  be  effected  in  one  of  two 
ways; 

a)  copies  of  the  originad  are  made  and  are  sent  to  all  of  the  intended  recipients,  eis 
described  above.  Thereafter,  the  copies  no  longer  are  subject  to  the  routing  of  this 
message  instance. 

b)  the  original  message  is  sent  to  all  of  the  intended  recipients  simultaneously.^  Sub¬ 
sequently,  the  original  can  be  routed  to  further  sites  after  all,  or  some,  of  the  reci¬ 
pients  have  processed  it.  (See  Figure  1.) 


4  This  technique  may  be  used  to  create  instances  of  a  type  whose  definition  is  a  subset  or  superset  of  the  current 
type's  definition.  In  this  case,  only  the  appropriate  fields  would  be  copied  to  the  new  instance. 

5  TThile  such  routing  is  not  possible  in  a  paper  system,  it  is  in  an  electronic  environment. 
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Figure  1.  Possible  Instance  Flows 


In  the  latter  case,  since  no  copies  are  actually  made,  any  updates  made  by  any  of  the 
recipients  are  reflected  on  the  origincd.  In  the  former  case,  the  copies  exist  independent  of 
the  original.  Updates  made  to  copies  (the  original)  do  not  necessarily  need  to  be  reflected  on 
the  original  and  other  copies  (the  copies).  On  the  other  hand,  they  may  be  reflected  if  the 
system  allows  it  [TsichBSb].  Our  MMS  incorporates  alternative  b)  above.  An  MMS  system 
should  also  support  a),  as  copies  can  always  be  made  and  routed.  This  is  not  the  intent  of 
concurrently  routing  an  instance. 

The  synteix  and  sememtics  of  the  routing  specification  language  must  allow  both  sequen¬ 
tial  and  concurrent  routing.  Intuitively,  concurrent  routing  appears  to  add  significeint  com¬ 
plexity  to  routing  evaluation,  unless  restrictions  are  made.  Consider  a  message  instance 
that  is  sent  to  r  recipients  concurrently.  The  r  recipients  collectively  make  up  a  site  in  the 
routing.  If  the  specification  of  the  routing  after  each  recipient  has  processed  the  message  is 
allowed  to  be  different,  then  we  may  have  up  to  r  individual  routing  specifications  to  evalu¬ 
ate.  If.  however,  the  semantics  of  concurrent  routing  demand  that  all  r  recipients  must 
evaluate  the  same  routing  specification,  then  the  problem  is  simplified  significantly;  r-1 
fewer  specifications  need  potentially  be  evaluated.  The  latter  approach  is  more  intuitively 
appealing  when  considering  a  single  instance  being  shared  by  r  recipients.  One  expects  the 
single  instance  to  be  routed  to  a  common  destination  (perhaps  a  concurrent  one)  by  all  r 
recipients.  This  is  the  approach  we  support. 
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2.A.  Koutin^;  and  Schema  DisLribuUon 

I  he  preceding  discussion  assumes  lhal  a  message  instance  of  some  message  type  will  be 
understood  at  the  recipient  site.  The  instance  will  only  be  meaningful  (as  an  instance)  at 
the  site  if  the  site  possesses  the  corresponding  message  type  specification.®  This  raises  the 
question  of  when  and  how  message  type  routing  and  schema  specifications  are  distributed 
throughout  the  message  management  system. 

A  routing  specification  may  either  travel  with  each  instance  as  it  flows  around  the  sys¬ 
tem  or  be  included  in  the  type  specification  that  is  stored  at  each  appropriate  site.  The 
former  technique  corresponds  to  a  Message  Logic  addressing  scheme,  and  the  latter  to  an 
Address  Logic  addressing  scheme;  a  combination  of  the  two  schemes  is  a  Mixed  Logic  scheme 
[Tsich82c].  The  former  implies  that  the  routing  specification  is  stored  at  the  origin 
station(s)  only  and  that  we  have  "large"  instances.  (That  is,  a  message  instance  package 
would  consist  of  the  actual  message,  the  routing  specification,  and  potentially  the  message 
schema  —  a  significant  use  of  bandwidth.)  The  latter  implies  increased  storage  requirements 
at  each  station  but  smaller  instances  flowing  around.  Given  that  network  bandwidth  is  in 
genercil  a  more  precious  commodity  than  secondary  storage,  the  latter  method  of  binding 
routing  specifications  to  message  type  specifications  is  more  appealing. 

The  routing  specification  for  a  message  type  consists  of  the  specification  of  the  routing 
from  each  site  involved  in  the  routing.  Thus,  the  routing  at  each  site  can  be  considered 
independently.  The  specification  at  each  site  for  a  message  type  is  "self-contained"  (depends 
on  instance  and  local  system  state,  but  not  on  other  site  routing  specifications),  and  the 
total  specification  can  be  cleanly  partitioned,  'rhe  combination  of  all  the  site  specifications 
allows  for  many  possibilities,  but  each  site’s  routing  is  well-defined.  By  storing  routing 
specifications  with  type  specifications  at  the  various  sites,  each  site  need  only  store  the 
decomposed  routing  specification  for  that  site,  as  opposed  to  the  total  routing  specification. 

Note  that  decomposed  routing  specifications  may  be  stored  at  the  sites  only  if  type  rout¬ 
ing  is  used.  For  instance  and  override  routing,  the  routing  specifications  travel  with  the 
insteince.  We  therefore  have  a  Mixed  Logic  scheme. 

Message  type  schemas  can  become  known  to  sites  in  a  number  of  ways.  First,  the  mes¬ 
sage  type  specifications  can  travel  with  the  instance.  This  is  tolerable  for  infrequently  sent 
types,  but  it  is  bad  for  frequently  used  types  because  much  bandwidth  is  wasted  in  communi¬ 
cating  the  routing  specification.  Second,  the  CBA  can  create,  at  some  initialization  time 
before  any  instances  eire  sent,  the  messeige  type  locally  for  each  of  the  sites  in  a  message’s 
routing  (a  rather  time  consuming  exercise).  Third,  the  CBA  can  create  the  type  globally,  at 
some  initialization  time  at  an  "administrative  station,"  and  send  the  type  specifications  to 
each  affected  user.  Fourth,  the  inclusion  of  a  site  in  a  routing  specification  may  automati¬ 
cally  effect  the  sending  by  the  system  of  the  type  to  that  site.  In  this  case,  at  type  creation, 
the  schema  would  be  sent  to  each  referenced  site.  For  override  or  instance  routing,  any  site 
not  previously  mentioned  is  sent  an  oat  hoc  copy  of  the  schema,  either  with  or  preceding  the 
instance.  Fifth,  a  site  p  not  understanding  the  type  for  a  received  instance  could  request  the 
type  specifications  from  either  the  originating  site  (0)  or  the  preceding  site  (p~l).  The  type 
schema  could  either  be  sent  for  the  lifetime  of  the  instance  causing  the  schema  to  be 
needed  at  site  p  or  for  a  longer  period,  remaining  at  p  for  each  successive  instance  of  that 
messege  type.  This  method  is  wasteful  in  time  and  bandwidth,  it  also  ignores  explicit  infor¬ 
mation,  namely  the  set  of  sites  included  in  the  type  s  or  instance  s  routing.  Finally,  some 
message  types  could  be  known  in  the  system  to  be  understood  by  all  users  as  part  of  their 
jj^  the  system.  To  reduce  network  bandwidth  consumption  at  run  time,  message 
schemas  should  be  stored  at  sites  whenever  possible. 

From  the  preceding  discussion,  we  identify  the  following  techniques  as  most  suitable  for 
distribution  of  message  schemas  and  routings  in  the  MMS  environment. 


6  [Ellis0O]  refers  to  this  and  other  consistency  req-airements  as  Message  Transmission  Semantics. 
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a)  Member 

Some  message  types  are  knovm  in  the  system  to  be  understood  by  all  users  as  part 
of  their  membership  in  the  system.  Routings  may  or  may  not  be  specified  for  these 
types. 

b)  JmpLicit 

The  inclusion  of  a  site  in  the  routing  specification  automatically  effects  the  sending 
by  the  system  of  the  message  type  to  the  site.  At  type  creation,  the  schema  would 
be  sent  to  each  referenced  site,  The  routing  specifications  are  decomposed  by  site, 
and  each  partition  is  sent  at  type  creation  to  the  corresponding  site. 

c)  Explicit 

The  CBA,  at  some  "administrative  station,"  can  send  the  message  type 
specifications  explicitly  to  some  group  of  sites.  This  may  occur  at  type  creation  or 
some  other  time.  Recall  that  not  all  message  instances  flowing  in  the  system  will 
have  routing  specifications  associated  with  their  types.  Explicit  distribution  is  use¬ 
ful  for  a  message  t3pe  for  which  there  is  no  prespecifiable  routing  but  for  which  an 
identifiable  group  of  probable  destinations  exists.  Routing  specifications,  if 
specified  for  an  instance,  would  travel  with  the  instance. 

d)  M  Hoc 

For  override,  instance,  and  manual  routing,  any  site  not  possessing  the  message 
schema  is  sent  a  temporary  copy  of  the  schema,  either  with  or  preceding  the 
instance.  This  copy  of  the  schema  is  discarded  when  the  site  has  processed  the 
instance,  since  the  routing  was  ad  hoc  and  not  highly  likely  to  recur.  The  total 
routing  instructions  travel  with  the  instance. 

These  methods  provide  a  flexible  distribution  of  message  types  and  routing 
specifications  through  the  MMS. 

2.5.  Routing  Evaluation 

There  are  three  possible  methods  for  the  evaluation  of  routing  specifications  for  a  mes¬ 
sage  instance.  Central  evaluation  requires  a  central  authority  to  evaluate  the  routing  after 
each  site  completes  processing  the  instance.  This  involves  much  wasted  communication  to 
and  from  the  central  station,  introduces  a  potential  system  bottleneck,  and  defeats  the  pur¬ 
pose  of  a  distributed  system  of  autonomous  workstations.  An  advantage  is  that  the  evalua¬ 
tion  software  need  only  exist  at  the  central  authority  and  thus  is  probably  easier  to  main¬ 
tain.  A  problem  arises  if  the  station  housing  the  central  authority  goes  down. 

Origin  evalualion  involves  the  originating  station  making  all  routing  decisions  at  the 
time  of  instance  dispatch.  This  is  not  feasible  if  routing  decisions  will  be  made  on  the  basis 
of  changing  parameters  (such  as  system  characteristics  or  field  values).  The  routing  evalua¬ 
tion  software  exists  in  each  workstation,  but  it  is  only  used  once  (at  the  originating  station) 
for  each  instance  being  sent. 

Distributed  evaluation  requires  that,  after  each  site's  processing  is  complete,  the 
corresponding  workstation  evaluates  the  decomposed  routing  and  sends  the  instance  on  to 
the  next  site.  This  evaluation  is  most  suitable  for  the  requirements  of  a  distributed  system. 
The  evaluation  software  exists  in  all  stations,  but  for  a  specific  message  instance  the 
software  is  used  only  at  stations  that  house  sites  of  the  instance’s  actual  routing. 

Since  the  routing  specifications  for  message  types  can  be  partitioned  according  to  site 
and  a  MMS  environment  consists  of  a  distributed  system  of  autonomous  workstations,  a  dis¬ 
tributed  evaluation  scheme  seems  most  appropriate  for  message  type  routing.  For  override 
and  Instance  routing,  the  total  routing  specification  travels  with  the  instance.  After  the 
instance  has  been  processed,  the  site's  workstation  evaluates  that  site’s  portion  of  the  total 
routing  specification  to  determine  the  next  sile.  The  evaluation  software  for  override  and 
instance  routing  specifications  will  be  more  complex  than  that  for  type  routing;  for  the 
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former,  the  current  site  s  specification  must  be  found  among  all  the  other  site  specifications 
before  actual  evaluation  takes  place, 

The  triggering  of  the  routing  evaluation  at  each  site  occurs  when  the  user  is  finished 
processing  the  instance.  The  user  informs  the  system  of  this  fad  (either  explicitly  or  impli¬ 
citly),  and  the  system  evaluates  the  routing  criteria  and  routes  the  instance  appropriately. 
For  example,  by  moving  the  instance  to  a  mail  out-tray,  the  user  could  explicitly  trigger 
routing  evaluation.  Local  automatic  procedures  defined  for  message  types  may  implicitly 
trigger  routing  evaluation  [HoggB3a,  Fong83].  Routing  evaluation  may  also  be  implicitly  trig¬ 
gered  by  a  duration  expiring  for  an  instance  at  a  site. 

2.6.  A  Routing  Specification  Language 

A  routing  specification  language  is  necessary  to  enable  the  CBA  and  the  users  to  convey 
to  the  system  the  routings  desired  for  messages  in  the  system.  System  facilities  eire 
required  to 

a)  specify  routings. 

b)  trace  a  message  instance. 

c)  check  an  instance’s  state  in  the  system. 

d)  edit  and  override  routings. 

In  the  routing  specification  language,  the  following,  at  least,  should  be  testable  decision 
criteria; 

a)  values  of  fields  in  a  message  instance  (and  the  existence  of  vedues). 

b)  the  origin,  current,  and  previous  sites  of  a  message  insteince. 

c)  the  values  of  certedn  system  parameters. 

d)  time  constraints,  such  as  durations  and  time  limits.  These  should  be  expressable 
as  fixed  length  (e.g..  7  days.  1  week),  specific  (e.g.,  October  16.  1982),  or  periodic 
(e.g.,  every  3  days)  entities. 

e)  the  number  of  times  the  instance  has  been  processed  previously  at  the  site. 

f)  simple  boolean  expressions  of  certain  combinations  of  the  above. 

The  actions  that  are  possible  include 

a)  routing  to  a  destination  (in  either  a  sequential  or  concurrent  manner). 

b)  quitting  (that  is,  no  further  routing  will  occur  for  this  instance). 

c)  alerting  (that  is.  notifying  a  user  of  some  situation;  e.g.,  an  alert  may  be  issued  if  a 
time  limit  is  exceeded). 

d)  rerouting  (that  is,  in  an  exceptional  case,  taking  an  instance  away  from  a  given  site 
and  routing  it  to  another  site). 

To  facilitate  the  above  capabilities,  the  routing  system  should  incorporate  notions  of  ori¬ 
gin,  previous,  and  current  sites  for  an  instance  and  of  time-stamped  instances  (either  for 
the*  current  site  only  or  for  each  site  traversed).  These  notions  are  especially  important  for 
tracing  the  communication  history  of  a  message  instance,  for  making  routing  decisions 
based  on  instance  location,  and  for  effecting  time-limited  processing. 

3.  A  ROUTING  SPECIFICATION  LANGUAGE 

In  the  preceding  section,  we  developed  a  framework  for  the  specification  of  routings  for 
messages  in  a  message  management  system.  A  routing  specification  Language  is  presented 
here,  with  several  illustrative  examples. 
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3.1.  TAfiffliage  Definition 

The  following  prototype  routing  specification  language  incorporates  the  features  dis¬ 
cussed  in  the  preceding  section.  The  language  enables  the  CBA  and  the  users  to  describe  to 
the  system  the  routings  desired  for  messages  in  the  system.  A  routing  specification  for  a 
messeige  type  consists  of  a  set  of  subspecifications,  one  for  each  potential  site  in  the  routing. 
For  each  site,  the  set  of  possible  destinations  is  identified,  each  perhaps  qualified  by  some 
decision  criteria.  As  well,  time  constraints  on  instance  processing  may  be  specified. 

The  BNF  specification  in  [Mazer83]  represents  the  current  form  of  the  language.  We 
present  below  the  general  format  of  a  routing  specification.  All  language  keywords  are 
presented  in  upper  case;  all  non-ke3words  are  in  lower  case.  Metasymbols  are  enclosed  in  left 
and  right  arrowheads  such  as  <this>.  The  format  is 

DEFINE  <sitelist>  =  <list  of  site  names> 


DEFINE  <sitelist>  =  <list  of  site  names> 

SITE  <site  name>  <source/nosource> 

TIME-CASE  <conditions>  :  <time  constraints>  :  <actions> 

<time  constraints>  :  <actions> 


TIME-CASE  <conditions>  ;  <time  constraints>  :  <actions> 

<time  constraints>  ;  <actions> 
CREATION  {valid  only  if  SOURCE  specified  in  SITE  line  above] 

TIME-CASE  <conditions>  ;  <time  constraints>  :  <actions> 

<time  constraints>  :  <actions> 


TIME-CASE  <conditions>  ;  <time  constraints>  :  <actions> 

<time  constraints>  :  <actions> 
CASE  <conditions>  TO  <next  site> 


CASE 

FIRST 


<conditions>  TO  <nextsite> 

/ 

|to  be  checked  upon  first  visit  to  this  SITE] 


SECOND 


{to  be  checked  upon  second  visit  to  this  SITE] 


{THIRD,  FOURTH,  etc.] 
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OTHER  ^an  optional  default  case| 


ERROR  ^for  run  time  exception  handling] 


END 


jmore  SlTEs] 

SITE  <site  name>  <source/nosource> 


END 


<source/nosource>  is  the  optional  keyword  SOURCE,  which  indicates  whether  the 
current  site  is  allowed  to  create  instances  of  this  type.  SOURCE  specification  is  distinct  from 
any  authorization  specifications  for  message  instance  creation  [TYooBS],  although  no  incon¬ 
sistencies  are  allowed  Zero  or  more  DEPiNE  statements  may  be  specified  to  apply  to  all  the 
sites.  DEFINE  is  used  to  specify  a  list  of  sites  for  use  in  a  CASE  specification,  as  in  Example  2 
below.  <sitelist>  refers  to  the  list  of  sites  specified  in  <list  of  site  names>  by  either  con¬ 
current  or  sequential  routing.  Zero  or  more  TIME-CASEs,  zero  or  one  of  each  visit  keyword 
(CREATION,  FIRST,  SECOND,  .  .  .).  zero  or  one  OTHER,  and  zero  or  one  ERROR  may  be  specified 
for  a  site.  Tlie  TIME-CASE  construct  is  used  for  specifying  time  constraints,  such  as  dura¬ 
tions  or  time  limits,  on  message  instance  processing.  TTie  <actions>  associated  with  TIME- 
CASEs  currently  are  ALERTs  and  REROUTES  (c.f.  Section  2.6).  The  visit  keywords,  which  must 
appear  in  ascending  order,  delimit  the  subspecifications  that  are  to  apply  to  each  visit  of  an 
instance  to  the  site.  Each  visit  keyword  is  optional,  but  the  ordering  of  existing  visit 
subspecifications  is  enforced.  Note  that  the  SOURCE  ke3^ord  must  appear  for  any  site  for 
which  a  CRPIATION  visit  is  specified.  OTHER  specifies  criteria  to  be  used  on  any  visit  when  the 
visit  specification  does  not  cover  the  current  instance  state  or  there  is  no  visit 
subspeciftcation  for  the  current  visit,  ERROR  allows  for  exception  handling  at  run  time.  The 
two  possible  types  of  errors  are  no  CASE  condition  holding  true  within  a  visit  or  OTHER 
subspecification,  and  neither  the  visit  subspecification  nor  the  OTHER  subspecification  exist¬ 
ing  for  the  current  visit  of  the  instance  to  a  site  (for  example,  only  FIRST  and  SECOND  are 
specified  for  a  message  type,  and  an  instance  visits  for  a  third  time).  Alerts  and/or  rerout¬ 
ing  to  some  type-related  role,  to  the  CBA,  or  to  some  error  handling  role  are  the  most  likely 
actions  upon  error.  Only  alerts  are  supported  currently. 

Zero  or  more  TIME-CASEs  and  zero  or  more  CASEs  may  be  specified  per  visit.  A  CASE  con- 
gt_j-Qct  specifies  conditions  which  must  hold  true  for  the  instance  to  be  forwarded  to 
<next  site>.  <next  site>  may  be  a  site  name  or  a  role  abstraction,  as  in  Example  4  below. 
The  CASEs’  conditions  must  be  sufficiently  specified  so  as  to  be  mutually  exclusive,  as  no  ord¬ 
ering  is  imposed  on  the  CASEs  within  a  visit;  for  ambiguous  CASE  specifications,  no  evalua¬ 
tion  order  is  guaranteed.  TIME-CASEs  are  separated  from  routing  CASEs  at  parse  time. 
TIME-CASEs  are  checked  upon  an  instance's  arrival  at  a  site  and  periodically  during  the 
instance’s  residence  at  the  site,  whereas  CASEs  are  involved  only  during  the  routing  evalua- 
instance  has  been  fully  processed  at  the  site.  Comments  are  allowed  in  the 
routing  language.  Comments  sire  considered  to  be  any  string  of  characters  contained 
between  a  matching  pair  of  ^  and  ]. 
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Two  specification  subformats  are  especially  important  in  that  they  will  probably  be  used 
very  often: 


Subformat  1 


SITE  <site  name> 

TO  <next  site> 

END 


Hiis  subformat  is  for  unconditional  routing  of  all  instances  at  the  current  site  to 
<next  site>.  Recall  that  the  evaluation  of  an  instance's  routing  specification  must  be  expli¬ 
citly  or  implicitly  triggered  at  the  site.  An  instance  does  not  merely  "pass  through"  the  site 
but  may  be  processed  first  before  routing  occurs. 

Subformat  2 

SITE  <site  name> 

END 


This  subformat  specifies  the  termination  of  the  message  instance's  tour  at  the  current  site 
upon  the  first  visit. 

Each  of  the  two  subformats  may  be  extended  to  visits  as  well.  For  example,  a 
specification  such  as 

SITE  <site  name> 

FIRST 

TO  <next  site> 

SECOND 

END 

indicates  that,  on  the  FIRST  visit  to  this  site,  an  instance  is  to  be  unconditionally  routed  to 
<next  site>.  and  on  the  SECOND  visit  to  this  site,  the  instance  is  to  terminate  its  system 
tour.  Note  that  Subformat  1  above  is  the  same  as 

SITE  <site  name> 

OTHER 

TO  <next  site> 

END 

and  Subformat  2  is  the  same  as 

SITE  <site  name> 

FIRST 

END 

The  ampersand  is  used  in  a  DEFINE  statement's  site  list  to  specify  concurrent  routing, 
as  in  the  following  example: 

grad-secretary  8c  grad-chairperson  Sc  phd-admissions-officer 
In  this  case,  each  of  the  three  roles  specified  above  will  receive  the  message  instance  con¬ 
currently.  Known  concurrency  control  techniques  may  be  used  to  effect  concurrent  access 
[BernsBl].  Implicit  sequential  routing  is  the  default  routing  technique  in  the  language. 
Sequential  routing  may  be  explicitly  specified  in  a  DEFINE  statement  with  a  right  arrowhead 
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indicdUng  the  sequence,  as  in 
mazoo  >  david  >  brian 

In  this  case,  the  instance  flows  unconditionally  from  mazoo  to  david  to  brian.  This  sequential 
specification  must  be  expanded  at  parse  time.  Note  that  the  address  notation  used  here  is 
one  of  convenience  only  and  does  not  presume  to  represent  nor  restrict  the  address  notation 
used  in  any  message  management  system.  A  number  of  annotated  examples  follow  and  serve 
to  introduce  the  language. 

3.2.  Some  Routing  Examples 


Example  1 

MESSAGE  TYPE;  phd-appl-form 

DEFINE  grad-committee-members  =  seveik  &:  graham  &  holt 

SITE  grad-secretary  SOURCE 
TIME-CASE  ;  TIME-LIMIT  14  DAYS  :  ALERT 

"Please  examine  ph.d.  graduate  application"  END-TIME 
CREATION 

TO  phd-admissions-officer 
FIRST 

CASE  ?status  =  "rejected"  TO  rejection-file 
CASE  ?status  =  "accepted"  TO  acceptance-file 
ERROR 

ALERT  "Illegal  message  instance  state;  contact  CBA" 

END 

SITE  phd-admissions-officer  SOURCE 
CREATION 

TO  grad-committee-members 
FIRST 

CASE  ?status  =  "rejected"  TO  grad-secretary 
CASE  ?status  =  HAS-NO-VALUE  TO 

grad-committee-members 

SECOND 

TO  grad-secretary 
END 

SITE  grad-committee-members 
nRST 

CASE  ORIGIN  =  grad-secretary  TO  phd-admissions-officer 
CASE  ORIGIN  =  phd-admissions-officer  TO  grad-coordinator 

END 

SITE  grad-coordinator 
FIRST 

TO  grad-secretary 
END 

SITE  rejection-file 
END 


SITE  acceptance-file 
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END 


This  example,  for  a  Ph.D.  program  admissions  form,  serves  to  illustrate  several  routing 
specification  features.  First,  notice  that  a  TIME-CASE  has  been  specified  for  site  grad- 
secretary,  This  applies  to  all  visits  within  the  site,  unless  overridden  by  a  visit-specific, 
conflicting  TIME-CA^  (i.e.,  one  with  the  same  condition).  In  this  example,  if  the  instance  is 
not  acted  upon  at  this  site  within  14  days  of  arrival  at  the  site,  an  alert  message  is  sent  to 
the  role.  Consider  further  the  subspecification  for  grad-secretary.  The  site  is  allowed  to 
create  instances  of  this  type,  as  indicated  by  the  keyword  SOURCE.  If  the  instance  is  being 
sent  away  after  having  just  been  created  (i.e.,  this  will  be  the  initial  routing  of  this  instance, 
as  determined  by  the  CREIATION  visit  specification),  then  the  instance  is  sent  to  phd- 
admissions-officer.  On  the  first  visit  of  the  instance  to  grad-secretary,  the  applicant’s  status 
is  checked.  If  the  applicant  has  been  rejected  (as  indicated  by  a  query  to  the  status  field  of 
the  message),  then  the  instance  is  sent  to  rejection- file  (an  instance  of  a  FILE  system 
server).  If  the  applicant  has  been  accepted,  then  the  instance  is  sent  to  acceptance-file.  Any 
instance  state  at  grad-secretary  not  covered  by  the  subspecification  is  an  error.  This 
applies  both  to  states  not  covered  under  a  certain  visit’s  specification  (e.g.,  FIRST)  and  to 
visits  not  specified  at  all  (e.g..  if  an  instance  of  phd-appl-form  were  to  visit  grad-secretary  a 
second  time).  The  ERROR  subspecification  indicates  the  action  to  be  taken;  in  this  exeimple, 
the  role  is  alerted  and  instructed  to  contact  the  CBA 

Consider  now  the  phd-admissions-oflicer  subspecification.  If  phd-admissions-officer  has 
just  created  the  instance,  then  it  is  sent  to  grad-committee-members.  The  destination 
grad-committee-members  is  defined  locally  to  this  message  type  routing  to  be  a  set  of  sites 
intended  to  receive  the  instances  concurrently.  Using  a  DEFINE  statement  and  the 
corresponding  sitelist  name  is  the  only  way  to  specify  a  concurrent  routing  "site."  This  is  to 
prevent  the  complexity  discussed  in  Section  2.3.  On  the  instance’s  first  visit  to  phd- 
admissions-officer,  if  the  applicant  is  rejected,  then  the  instance  is  sent  to  grad-secretary.  If 
the  applicant's  status  is  not  yet  known,  then  grad-committee-members  receive  the  instance. 
(This  will  occur  when  the  instance  originated  with  grad-secretary  and  phd-admissions-officer 
did  not  reject  the  applicant.)  On  the  instance's  second  visit  to  phd-admissions-officer,  it  is 
directed  to  grad-secretary,  regardless  of  the  message  state.  In  fact,  due  to  the  application 
procedure  definition,  an  instance  visiting  phd-admissions-officer  a  second  time  will  have 
come  from  grad-committee-members.  In  the  subspecification  for  grad-committee-members, 
if  the  origin  of  this  instance  was  grad-secretary  (as  determined  by  a  query  to  the  system 
instance  parameter  ORIGIN),  the  instance  is  routed  to  phd-admissions-officer.  If  the  origin 
was  phd-admissions-officer,  the  instance  is  routed  to  grad-coordinator.  From  grad- 
coordinator,  the  instance  is  unconditionally  routed  to  grad-secretary.  The  keyword  ORIGIN  is 
used  to  test  for  the  identity  of  the  originating  site.  ORIGIN  and  PREVIOUS  (the  previous  site 
of  this  instance)  are  values  (parameters)  implicitly  associated  by  the  system  with  each  mes¬ 
sage  instance.  For  the  site  rejection-file,  an  insteince  on  its  first  visit  will  cease  its  tour  of 
the  system.  Obviously,  any  further  visits  to  rejection-file  must  be  in  error.  Presumably, 
when  an  instance  is  sent  to  rejection-file,  the  message  is  to  be  stored.  The  terminating  sites, 
such  as  acceptance -file  and  rejection-file,  must  be  specified  explicitly.  This  aids  in  routing 
debugging,  office  procedure  specification  and  verification,  and  routing  analysis. 

The  '?'  notation  is  used  to  indicate  a  query  to  a  field  of  the  message.  (In  the  above 
example,  the  instance  field  status  is  queried.)  System  variables,  such  as  ORIGIN  and  PREVI¬ 
OUS,  are  keywords  in  the  language,  since  there  is  only  a  small  set  of  known  system  parame¬ 
ters  that  can  be  tested. 
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Example  2 

MESSAGE  TYPE:  baseball-reminder 

DKKINE  playermanfXfter  =  niazoo  k  frcd  david  & 

propp  &  manager 

DEIHNE  playercoach  =  mazoo  &  fred  &:  david  & 

propp  &  coach 

SITE  coach  SOURCE 
CREATION 
TO  playermanager 
END 

SITE  manager  SOURCE 
CREATION 
TO  playercoach 
END 

SITE  NOT  ORIGIN 
FIRST 

TIME-CASE  :  DURATION  =  3  DAYS 
END 


This  example  illustrates  a  message  that  is  to  be  sent  concurrently  to  five  recipients, 
after  which  the  messeige  instance  is  finished  its  tour.  The  five  recipients  are  specified  by 
predefined  lists  using  the  DEFINE  keyword.  The  list  to  be  used  depends  upon  which  of  the  two 
possible  sources  creates  the  instance.  The  NOT  ORIGIN  site  subspecification  must  be 
expanded  to  all  the  applicable  sites. 


Example  3 


MESSAGE  TYPE;  bulletin 

SITE  ANY  SOURCE 
CREATION 
TO  bulletin-board 
END 

SITE  bulletin-board 
FIRST 

TIME-CASE  :  DURATION  =  7  DAYS 
END 


In  this  example,  a  bulletin,  from  any  source,  is  to  be  posted  on  the  bulletin-board  (prob¬ 
ably  sent  to  a  common  workstation  or  common  data  area)  for  a  duration  of  one  week,  after 
which  it  is  to  be  discarded.  The  disposal  action  is  implicitly  specified  in  the  FIRST  visit 
subspecification  of  site  bulletin-board,  because  no  TO  or  CASE  is  specified.  This  is  an  example 
of  specification  subformat  2  given  above.  Recall  that  TIME-CASEs  apply  to  an  instance  only 
until  routing  evaluation  is  triggered.  At  that  time,  any  CASEs  or  TOs  apply.  The  ANY  SOURCE 
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site  specification  must  be  expanded  to  encompass  all  authorized  sites. 


Example  4 

MESSAGE  TYPE:  project-approval 

SITE  systems-head  SOURCE 
CREATION 

TO  systems-manager 
FIRST 

CASE  ?budget  >  0  TO  approvals-file 

CASE  ?budget  <=  0  TO  rejections- file 
END 

SITE  systems-manager 
FIRST 

TIME-CASE  PREVIOUS  =  systems-head  : 

TIME-LIMIT  7  DAYS  ;  ALERT 

"Please  respond  immediately" 

END-TIME 

TIME-LIMIT  10  DAYS  : 

REROUTE  systems-vicepresident 
END-TIME 

CASE  ?budget  >  0  TO  accounting 

CASE  ?budget  <=  0  TO  systems-head 
END 

SITE  systems-vicepresident 
FIRST 

TIME-CASE  PREVIOUS  =  systems-manager  ; 

TIME-LIMIT  EVERY  3  DAYS  :  AI.ERT  END-TIME 

CASE  ?budget  >  0  TO  accounting 

CASE  ?budget  <=  0  TO  systems-head 
END 

SITE  approvals-file 
END 

SITE  rejections-flle 
END 


This  example  illustrates  several  important  features.  A  project- approval  instance  is  sent 
from  its  originator,  systems-head.  to  systems-manager.  If  systems-manager  does  not  finish 
processing  the  instance  within  7  days,  an  alert  with  the  optionally  specified  string  message  is 
generated  to  systems-manager  (any  destination  could  be  alerted).  If  the  instance  is  not  pro¬ 
cessed  within  10  days  of  receipt,  the  message  instance  is  rerouted  automatically  to 
systems-vicepresident.  Note  that  the  subspcciflcalion  must  exist  for  the  site  receiving  the 
rerouted  message  —  the  arrival  due  to  a  rerouting  is  counted  as  a  regular  visit.  A  standard 
alert  is  sent  to  systems-vicepresident  every  3  days  until  the  instance  has  been  fully  pro¬ 
cessed.  At  either  systems-manager  or  systems-vicepresident,  if  the  project  was  given  some 
funding,  as  indicated  by  a  query  to  the  budget  field  of  the  instance,  then  the  message  is  sent 
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to  accounting.  If  the  project  was  not  given  funding,  the  message  is  sent  back  to  systems- 
head.  At  systems-head,  if  the  project  was  given  any  funding,  then  the  instance  is  sent  to 
approval s-file.  If  no  funding  was  given,  the  instance  is  given  to  rejections-file.  Note  that  the 
PREVIOUS  conditions  specified  in  the  TIME-CASE  constructs  for  systems-manager  euad 
systems-vicepresident  were  not  necessary  and  are  included  here  only  for  completeness. 
Because  of  the  office  procedure  specification  upon  which  this  routing  specification  is  based, 
an  instance  visiting  systems-manager  for  the  first  time  must  have  been  sent  from  systems- 
head,  or  else  an  error  has  occurred.  Similarly,  a  first  visit  to  systems-vicepresident  must  be 
immediately  preceded  by  a  visit  to  systems-manager. 

The  site  accounting  is  an  example  of  a  site  specification  that  is  not  a  role.  Rather, 
accounting  is  an  abstraction  of  some  set  of  roles.  The  message  instances  are  directed  to  an 
entity  which  will  be  resolved  to  some  specific  site(s)  by  expanding  the  accounting 
specification  from  a  separate,  but  related,  routing  specification.  For  example,  instances 
could  be  directed  to  an  accounting  office  without  specifying  at  that  time  the  role(s)  within 
the  office  that  are  to  process  the  instances;  that  specification  could  be  done  separately  or 
even  manually. 


Example  5 

MESSAGE  TYPE:  project-abstract 

SITE  project-manager  SOURCE 
CREATION 
TO  division-head 
FIRST 
END 

SITE  division-head 
FIRST 

TO  project-manager 
END 


MESSAGE  TYPE:  project-abstract-copy 

SITE  division-head  SOURCE 
CREATION 
TO  jones 
END 

SITE  jones 
FIRST 
TO  smith 
END 

SITE  smith 
i'lRST 
TO  doe 
END 


SITE  doe 
END 
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This  example  illustrates  two  separate  routing  specifications  for  an  original  message 
insteuice  and  some  copies  of  that  instance.  The  specification  for  message  type  project- 
abstract  covers  original  instances,  and  the  specification  for  type  project-abstract-copy  cov¬ 
ers  copies.  Note  that  the  generation  of  the  copies  is  not  specified;  this  must  be  done  at  some 
higher  level,  either  by  automatic  procedures  associated  with  the  message  type  or  by  explicit 
user  direction.  Once  the  copies  are  generated,  as  instances  of  type  project- abstract-copy  in 
this  example,  they  are  subject  to  the  specified  routing. 

In  the  example,  the  original  instance  is  routed  after  creation  from  project-manager  to 
division-head  and  then  back  to  project-manager.  The  FIRST  visit  subspecification  is  required 
at  project-manager  to  indicate  that  the  instance  is  expected  to  return  to  that  site  and  that 
the  instance’s  tour  is  to  end  at  that  time.  Without  the  FIRST  subspecification,  the  first 
return  visit  to  project-manager  other  than  the  CREATION  visit  would  be  an  error.  The  single 
copy  generated  of  this  origined  is  sent  sequentially  from  division-head  to  jones,  smith,  and 
doe,  Note  that  the  copy  is  generated  at  division-head,  not  at  project-manager.  Copies  may  be 
generated  at  sources  different  from  the  sources  of  the  original. 

The  specification  for  the  project-abstract- copy  type  could  have  been  specified  more  suc¬ 
cinctly  using  implicit  sequential  routing,  in  the  following  manner. 

MESSAGE  TYPE:  project-abstract-copy 

DEFINE  the-group  =  jones  >  smith  >  doe 

SITE  division-head  SOURCE 
CREATION 
TO  the-group 
END 


Example  6 

MENAGE  TYPE;  time-card 

DEFINE  log-cash  =  ledger_clerk  &  cashier 

SITE  employee  SOURCE 
CREATION 
TO  supervisor 
OTHER 

TO  supervisor 
END 

SITE  supervisor 
OTHER 

CASE  ?approveJ  =  "yes"  TO  log-cash 
CASE  ?approval  =  "no"  TO  ORIGIN 
END 

SITE  log-cash 
TO  next-site 
END 


I  the  next  siU'  after  .  .  .  J 
\  .  .  .  the  concurrent  one  { 
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This  time-card  example  is  used  in  [Ellis82]  to  illustrate  the  Information  Control  Net 
model  of  office  systems.  )Ve  use  it  here  to  show  the  ease  with  which  the  example  can  be 
specified  in  terms  of  message  type  routing.  In  the  example,  instances  of  the  time-card  mes¬ 
sage  type  originate  with  an  employee.  Upon  creation,  the  instance  (after  being  filled  by  the 
employee)  is  routed  to  the  employee’s  supervisor.  The  supervisor,  while  processing  the 
instance,  either  approves  or  rejects  the  time  card  as  submitted.  If  approval  is  not  given,  the 
instance  returns  to  the  employee.  At  the  employee  site,  the  employee  reprocesses  the 
instance,  eind  the  instance  is  directed  back  to  the  supervisor.  Note  that,  while  the  CREATION 
and  OTHER  clauses  are  identical  in  body,  CREATION  must  be  specified  because  the  site  may 
originate  instances.  The  employee-to-supervisor  cycle  continues  until  the  supervisor 
approves  the  time  card  as  submitted.  The  instance  is  then  routed  concurrently  to  ledger- 
clerk  and  cashier,  the  former  for  logging  the  hours  and  the  latter  for  issuing  a  pay  slip.  Each 
of  ledger-clerk  and  cashier  will  handle  the  message  instance  as  if  the  instance  were  at  that 
site  alone,  within  the  constraints  of  the  concurrency  control  access  mechanism.  VHien  pro¬ 
cessing  at  log-cash  is  complete  (as  determined  perhaps  by  an  automatic  procedure  for  the 
type),  the  instance  will  be  routed  onward. 

One  could  envision  a  specialized  time-card  message  type  created  for  each  employee, 
with  the  employee  site  name  and  supervisor  destination  specified  appropriately.  At  the 
supervisor  site,  the  corresponding  site  name  would  be  specified.  An  alternative  is  to  retain 
the  generic  time  card  type  specification  and  to  use  a  routing  address  site  to  actually 
dispatch  the  Instance  from  the  source  employee  to  the  appropriate  supervisor.  The  following 
routing  specification  incorporates  that  technique. 


MESSAGE  TYT’E;  time-card 

DEFINE  log-cash  =  ledger-clerk  k  cashier 

SITE  <employee>  SOURCE 
CREA'nON 

TO  supervisor-select 
OTHER 

TO  supervisor-select 
END 


SITE  supervisor-select 
OTHER 

CASE  ORIGIN  =  employeel  TO  supervisor! 

CASE  ORIGIN  =  employee2  TO  supervisor2 

\  the  supervisors  need 
not  be  unique  for 
each  employee! 

END 

SITE  supervisor-of- employe  el 

OTHER 

CASE  ?approval  =  "yes"  TO  log-cash 

CASE  ?approval  =  "no"  TO  ORIGIN 
END 
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Each  employee  site  would  have  the  generic  <employee>  specification.  The  routing 
address  site  supervisor-select  would  correctly  route  the  instance  to  the  appropriate  supervi¬ 
sor.  By  centralizing  the  employee-supervisor  matching,  changes  to  the  employee-supervisor 
relationship  are  easily  contained  to  the  routing  address  site.  The  supervisor-select 
specification  above  is  brute-force  in  style  in  that  a  CASE  phrase  would  exist  for  each 
employee.  This  brute  force  technique  could  be  replaced  by  a  single  CASE  phrase  which 
queries  a  personnel  database  to  gain  the  necessary  supervisor  reference;  database  queries 
are  not  yet  incorporated  into  our  routing  specification  language.  An  interesting  question 
deals  with  where  the  routing  address  resides.  This  question  is  important  because,  in  our 
example,  a  large  number  of  employee  sites  will  be  sen^ng  messages  to  the  routing  site.  The 
CBA,  when  setting  up  the  routing  site,  should  pay  attention  to  any  localization  of  the 
employee  sites  on  some  small  group  of  workstations,  so  that  communication  can  be  minim¬ 
ized  on  the  network. 

4.  SUMMARY  AND  CONCLUDING  REMARKS 

This  paper  has  presented  a  framework  for  the  specification  of  routing  in  a  message 
management  system  and  a  prototype  routing  specification  language.  While  not  all  message 
types  may  have  a  routing  specified,  many  well-defined  or  routine  routing  sequences  can  be 
automated.  The  framework  provides  facilities  for  the  specification  of  several  kinds  of  rout¬ 
ings.  Routings  can  be  overridden  and  temporarily  changed  to  allow  the  handling  of  excep¬ 
tional  conditions.  The  routings  specify  a  message’s  complete  tour  of  the  system,  not  a  one- 
hop  movement  of  the  message  within  the  system.  Routings  are  evaluated  in  a  distributed 
and  dynamic  manner  to  provide  a  high  degree  of  flexibility,  A  prototype  routing  system  is 
being  implemented  as  part  of  the  development,  at  the  University  of  Toronto,  of  a  message 
management  system  [Mazer83]. 

We  have  developed  a  new  enmhasis  in  routing  specification  —  the  concept  of  the  message 
as  an  Independent,  "intelligent"'^ entity  guiding  itself  dynamically  through  the  system.  One 
could  argue  that,  by  partitioning  the  routing  specifications  and  distributing  the  partitions  to 
the  various  sites,  we  have  violated  the  principle  of  independent  message  entities  because  the 
sites  guide  each  message  instance  forward  dynamically  according  to  the  site  routing 
subspecification.  Perhaps  we  have  simply  reinvented  station-oriented  routing  techniques. 
We  believe  this  is  not  the  case.  The  partitioning  method  is  simply  an  expedient  implementa¬ 
tion  technique.  The  routing  framework  does  not  depend  upon  that  technique,  as  shown  by 
the  implementation  of  override  and  instance  routings,  where  the  routing  specifications  actu- 
zdly  reside  in  the  messege  (as  a  part  invisible  to  the  site  user).  A  pure  Message  Logic  scheme 
would  have  the  routing  evaluation  logic  travelling  with  the  instance  body  and  routing 
specifications,  with  the  sites  just  providing  local  information  such  as  identification.  The 
instances  decide  where  they  are  to  go  to  next.  Such  a  scheme  is  not  practical  in  our 
environment.  Our  Mixed  Logic  scheme  constitutes  progress  in  the  development  towards  Mes¬ 
sage  Logic  schemes.  Research  is  currently  underway  at  the  University  of  Toronto  into  Mes¬ 
sage  Logic  schemes  [Hogg 83b]. 

We  conclude  by  pointing  out  several  issues  that  require  further  investigation.  Recall 
that  the  routing  specifications  can  be  nicely  partitioned  according  to  sites.  Such  a  well- 
specified  message  routing  lends  itself  to  message  flow  modeling  and  analysis  techniques, 
such  as  those  in  [Ladd80,  Niers82,  Tsich88b].  As  well,  the  routing  specifications  can  be 
analysed  to  identify  those  messages  for  which  termination  is  guaranteed  and  those  for  which 
the  specifications  are  incomplete  with  respect  to  termination  criteria.  This  could  be  done  at 
"compile  time"  to  provide  a  verification  technique  for  the  routing. 

While  we  have  discussed  the  initial  specification  of  routing  for  a  message  type,  it  is  also 
possible  for  the  type  routing  specifications  to  change  at  some  later  point.  Two  issues  arise 


7  In  our  system,  a  more  correct  vievr  is  perhaps  that  of  an  intelligent  system  —  a  pure  Message  Logic  system  would 
incorporate  intelligent  messages. 
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from  this.  F^sl.  whal  happens  to  those  instances  currently  flowing  in  the  system  according 
to  the  original  specifications?  The  extant  instances  will  co-exist  with  the  new  ones  until  all 
the  extant  instances  have  been  fully  processed,  At  that  time,  the  original  routing 
specifications  may  be  discarded  by  all  sites  not  involved  in  the  new  specifications.  The  type 
specifications,  of  course,  must  be  retained  at  all  sites  where  instances  will  be  found.  Second, 
a  change  in  type  routing  specifications  may  affect  automatic  procedures  in  the  system 
[Hogg83a,  Fong83].  For  example,  an  automatic  procedure  may  be  waiting  to  trigger  on  the 
arrival  of  a  message  instance  that  now  will  not  arrive.  This  problem  is  significant  and 
requires  some  research  into  disengaging  messages  from  automatic  procedures. 

Whereas  the  individuals  that  fill  a  role  or  the  implementation  methods  of  a  system 
server  may  vary,  most  roles  are  expected  to  be  stable  entities  that  will  change  very  infre¬ 
quently.  When  they  do  change,  however,  the  routings  involving  the  chemged  destinations  are 
partially  invalidated.  An  automatic  mechanism  could  be  included  in  the  routing  system  to 
alter  the  routings  according  to  the  changes.  A  change  in  roles,  however,  may  indicate  a 
major  reorganization  of  the  infrastructure  and  procedures  represented  by  the  system.  It 
may  be  better,  therefore,  to  require  the  CBA  to  respecify  the  type  routings  according  to  the 
new  organizational  structure. 

Woo  describes  the  concept  of  a  virtual  mess-a^fe  type  in  a  MMS  [Woo83].  A  virtual  mes¬ 
sage  type  prescribes  a  view  on  the  communication  base  analogous  to  the  view  capability  in 
database  management  systems.  Virtual  message  types  are  combinations,  using  projection, 
restriction,  and  cross-product  operations,  of  parts  of  several  base  message  types.  Virtual 
message  instances  do  not  exist  as  separate  physical  entities;  they  exist  in  the  vailous  base 
message  types  being  combined.  'ITie  routing  of  virtual  message  types  is  an  interesting  prob¬ 
lem,  which  revives  in  a  more  complex  context  many  of  the  issues  raised  with  respect  to  base 
message  types  and  introduces  new  issues. 

Acknowledgement 

This  research  was  supported  by  a  Postgraduate  Scholarship  from  the  Natural  Sciences 
ajid  Engineering  Research  Council  of  Canada. 


Bibliography 


[Bems8l] 

[Birre82] 

[Chang82] 

[Econo82] 

[Ellis80] 

[Ellis82] 


Bernstein,  P.,  and  N.  Goodman.  "Concurrency  Control  in  Distributed  Database 
Systems."  Computing  Stnueys,  13,  No.  2,  (1981),  pp.  185-221. 

Birrell,  A.  D.,  R.  Levin,  R.  M.  Needham,  and  M.  D.  Schroeder.  "Grapevine:  An  Exer¬ 
cise  in  Distributed  Computing  "  ComunicatioTis  of  the  ACM,  25,  No.  4,  (1982),  pp. 
260274. 

Chang,  J-M.,  and  S-K.  Chang.  "Database  Alerting  Techniques  for  Office  Activities 
Management  "  IEEE  Transactions  on  Communications,  COM- 30,  No.  1.  (1982),  pp. 

74-81. 

Ec onom opoul us ,  P.  Acn  fynxige  Eatabase  Management  System,  M.Sc.  Thesis,  Depart¬ 
ment  of  Computer  Science,  University  of  Toronto,  Toronto  1982. 

Ellis,  C.  A,  and  G.  J.  Nutt.  "Computer  Science  and  Office  Automation."  Computing 
Surveys,  12,  No.  1,  (1980),  pp.  27-60. 

Ellis,  C.  .A.,  and  M.  Bernal.  "OfficeTalk-D:  An  Experimental  Office  Information  Sys¬ 
tem."  Proc.  S/GOA  Conference  on  Office  Information  Systems.  Philadelphia,  21-23 

June  1982,  pp.  131-140. 


-23- 


[FalouB2]  Faloutsos,  C.  Extendimj  a  D.B.M.S.  to  Handle.  Thxt.  M.Sc.  Thesis,  Department  of 
Computer  Science,  University  of  Toronto,  Toronto  1982, 

[Fong83]  Fong.  A.  C.  "A  Model  for  Automatic  Form-Processing  Procedures."  Proc.  Sixteenth 
Hawaii  fntemational  Conference  on  System  Sciences,  Honolulu,  5-7  January  1983, 
Vol.  1.  pp,  558-565. 

[Gehan82]  Gehani,  N.  H.  "The  Potential  of  Forms  in  Office  Automation."  IEEE  lYansactions  on 
Communications,  COM-30,  No.  1,  (1982),  pp,  120-125. 

[Hogg83a]  Hogg,  J.,  0.  Nierstrasz,  and  D.  C.  Tsichritzis.  "Form  Procedures."  IEEE  Transac¬ 
tions  on  Software  E^ngineering ,  1983  (to  appear). 

[HoggB3b]  Hogg,  J.,  et  al.  "An  Intelligent  Mail  System."  In  Beta  Gamma.  Ed.  D.  C.  Tsichritzis. 
Technical  Report  CSRG-150.  University  of  Toronto.  Toronto  1983. 

[Kroen77]  Kroenke,  D.  Database  Processing:  Eiindamentals,  Modeling,  J^lications.  Chi¬ 
cago;  Science  Research  Associates,  Inc.,  1977. 

[LaddBO]  Ladd,  1..  and  D.  C,  Tsichritzis.  "An  Office  Form  Flow  Model."  Proc.  AEIPS  National 
computer  Conference,  1980,  pp.  533-540, 

[Marti82a]  Martin,  P.,  and  D.  C.  Tsichritzis.  "A  Message  Management  Model."  In  Mpha  Beta.  Ed, 
F.  H.  Lochovsky,  Technical  Report  CSRG-143,  University  of  Toronto,  Toronto  1982. 

[Marti82b]  Martin,  P.  Office  Communication  Model.  Working  Paper,  Computer  Systems 
Research  Group,  University  of  Toronto,  Toronto  1982. 

[Marti82c]  Martin,  P.  A  Message  Management  Model.  Working  Paper,  Computer  Systems 
Research  Group,  University  of  Toronto,  Toronto.  September  1962. 

[Mazer83]  Mazer,  M.  S.  The  Specification  of  Routings  in  a  Message  Management  System. 

M.Sc.  Thesis.  Department  of  Computer  Science,  University  of  Toronto,  Toronto, 
1983. 

[McQui77]  McQuillan,  J.  M.  "Routing  Algorithms  for  Computer  Networks  —  A  Survey,"  Proc. 
National  Tele  communications  Conference ,  1977.  pp.  28:1-1  -  28:1-6. 

[Niers82]  Nierstrasz,  0.  M.,  and  D.  C.  Tsichritzis.  "Message  Flow  Modeling."  In  Alpha  Beta.  Ed. 

F.  H.  Lochovsky.  Techmcal  Report  CSRG-143,  University  of  Toronto,  Toronto  1982. 

[Parsn82]  Parsneau,  L.  "The  office  is  the  new  frontier  in  today’s  search  for  productivity." 
Canadian  Office,  13,  No.  10.  (1982),  pp.  16-17. 

[ShochTB]  Shoch,  J.  F.,  "Inter-Network  Naming,  Addressing,  and  Routing."  Proc.  IEEE  COMP- 
CON.  Fall  1978,  pp.  72-79, 

[ShuBl]  Shu,  N.,  V.  Lum,  F.  Tung,  and  C.  Chang.  "Specification  of  Forms  Processing  and 
Business  Procedures  for  Office  Automation."  IEEE  Transactions  on  Software 
Engineering,  SE-8,  No.  5.  (1982),  pp,  499-512. 

[StoneB2]  Stonebraker,  M..  and  J,  Kalash.  "TIMBER;  A  Sophisticated  Relation  Browser." 

Proc.  Elighth  International  Conference  on  Very  Large  Data  Bases,  Mexico  City.  8-10 
September  1982,  pp.  1-10, 

[TsichBO]  Tsichritzis,  D,  C.,  and  F.  H.  Lochovsky.  "Office  Information  Systems:  Challenge  for 
the  BO'S."  Proc.  IEEE,  68.  No.  9,  (1980),  pp.  1054-1059. 

[TsichBl]  Tsichritzis.  D.  C.  "Integrating  Data  Base  and  Message  Systems."  Proc.  Seventh 
International  Conference  on  Very  Large  Data  Bases,  Cannes,  9-11  September  1981, 
pp.  356-362. 

[Tsich62a]  Tsichritzis,  D,  C.,  F.  A.  Rabitti,  S.  Gibbs.  0.  M.  Nierstrasz,  and  J.  Hogg.  "A  System  for 
Managing  Structured  Messages."  IEEE  Transactions  on  Communications,  COM-30, 
No.  1.  (1982).  pp.  66-73. 


-24- 


[TsichH2b]  Isichrilzis,  D  C^  "P'orm  Managoinonl."  ComTnu7iix:atio'ns  of  the.  ACM,  25,  No.  7, 
(1982).  pp.  483-478 

[Tsich82c]  TsichriLzis,  D.  C.  "Addressing  Schemes  in  Message  Systems."  In  Beta  Gamma.  Ed. 

D.  C.  Tsichritzis.  Technical  Report  CSRG-150,  University  of  Toronto,  Toronto  1983. 

[VittaBl]  Vittal,  J.  "Active  Message  Processing:  Messages  as  Messengers."  Prov.  Proc.  Inter¬ 
national  Symposium  on  Computer  Message  Systems,  IFIP  TC-6,  Ottawa,  April  1981. 

[WooB3]  Woo,  C.  A  Communication  Base  Design  System  for  a  Message  Management  System. 
M.Sc.  Thesis,  Dept,  of  Computer  Science,  University  of  Toronto,  Toronto  1983. 

[ZloofBl]  Zloof,  M.  M.  "QBE/OBE:  A  Language  for  Office  and  Business  Automation."  IEEE 
Computer,  14.  No.  5,  (1981).  pp.  13-22. 


Forms  Programming  for  Non-Programmers* 

Dawid  L.  Propp 

Computer  Systems  Research  Group 
University  of  Toronto 

ABSTRACT 


A  significant  portion  of  the  forms  processing  that  takes  place  in 
an  office  Is  straightforward  and  routine,  two  features  that  lend  them¬ 
selves  to  automation.  Most  forms  management  systems,  however,  can¬ 
not  be  programmed  by  their  users.  The  typical  office  worker  is  well- 
versed  in  the  specifics  of  the  application,  not  in  the  specifics  of  pro¬ 
gramming. 

Office  workers  could  write  many  of  their  automated  forms- 
processing  procedures  by  using  a  promising  technique  called  program¬ 
ming  by  example,  combined  with  a  simple  model  of  forms  processing.  A 
user  writes  a  program  by  example  by  performing  the  task  on  an  actual 
example.  The  folder  model  of  forms  processing  structures  the  routine 
processing  of  forms  from  an  office  worker's  point  of  view. 

The  forms  programming  by  example  system  described  in  this 
thesis  provides  for  simple  command  recording,  program  generalization, 
conditional  execution,  and  loops.  It  structures  a  forms  procedure  Into 
four  stages:  collection,  action,  deadline,  and  disposal. 

1.  INTRODUCTION 

An  office  is  an  information  intensive  organization.  Information  is  edited,  organ¬ 
ized,  filed,  copied,  transformed,  analyzed,  and  transmitted.  The  form  is  a  common 
representation  for  much  of  the  information,  since  it  allows  the  information  to  be  pack¬ 
aged  in  a  format  that  facilitates  its  processing.  A  typical  form  effects  a  chain  of  pro¬ 
cessing  before  it  is  disposed  of.  Much  of  this  forms  processing  is  straightforward 
arid  routine,  features  that  lend  themselves  to  automation. 

The  users  of  such  a  forms  management  system--one  component  of  a  total  office 
information  system — are  secretaries,  administrative  personnel,  and  managers.  They 
are  well-versed  in  the  specifics  of  the  application;  they  are  not  well-versed  in  the 
specifics  of  programming  languages.  A  typical  office  forms  system,  however,  does 
not  provide  the  users  with  a  suitable  facility  for  transforming  their  knowledge  into  a 
working  procedure.  Programming,  in  its  current  form,  is  not  meant  for  everyone,  espe¬ 
cially  casual  users.  This  is  why  experts  are  required  to  write  programs  for  the  office 
workers.  Why  should  this  situation  persist?  A  facility  should  exist  within  a  forms 
management  system  for  non-programming  users  to  write  programs  for  procedures, 
without  first  acquiring  programming  skills.  Programming  by  example  [Halb81]  provides 
such  a  facility. 

The  user  should  not  have  to  forgo  his  knowledge  of  the  computer  system  inter¬ 
face  when  programming.  In  a  programming  by  example  system,  the  user  programs 
using  exactly  the  same  system  operations  he  already  knows.  Programming  capabili¬ 
ties  that  are  not  in  the  computer  system  interface,  such  as  control  structures,  are 
added  when  necessary,  but  in  general,  he  is  programming  in  the  user  interface  of  the 
system. 


*  This  work  Is  based  on  the  M.Sc.  thesis  by  David  Propp  [Prop83j. 
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The  user  must  also  be  able  to  try  his  program  out  as  he  is  writing  it.  Mentally 
simulating  a  program  and  predicting  its  cofisequoncos  are  difficult  skills  to  acquire.  In 
programrnirig  by  example,  the  user's  oommarids  are  recorded  as  he  operates  on  a 
copy  of  the  real  data.  He  programs  by  giving  an  example  of  what  he  wants  the  pro¬ 
gram  to  do;  program  creatibn  and  program  execution  occur  together.  The  results  of 
his  actions  are  immediately  visible,  thus  assuring  him  that  his  program  has  worked 
correctly. 

These  two  ideas,  programming  in  the  user  interface  of  the  system  and  program¬ 
ming  by  giving  an  example,  are  the  essence  of  the  programming  by  example  methodol- 
ogy.  The  user  writes  a  program  by  using  an  example  to  show  how  the  task  is  done. 
When  facilities  for  generalizing  the  example  program  and  for  specifying  control  struc¬ 
tures  are  added,  programming  by  example  can  be  used  to  write  quite  sophisticated 
programs. 

The  folder  model  of  forms  processing^  structures  a  forms  procedure  by  dividing 
it  into  four  stages.  It  is  designed  to  handle  the  routine  processing  of  forms — the  user 
handles  the  exceptions. 

In  the  forms  programming  system  presented  in  this  paper,  the  two  basic  goals 

are: 

(i)  to  structure  a  forms  processing  procedure  from  an  office  worker's  per¬ 
spective.  This  makes  procedure  specification  a  much  easier  task. 

(ii)  to  allow  non-programming  office  workers  to  write  these  forms  pro¬ 
cedures  without  becoming  proficient  in  a  conventional  programming 
language. 

The  folder  model  satisfies  the  former  objective,  while  the  programming  by  exam¬ 
ple  methodology  satisfies  the  latter  objective.  The  synthesis  of  these  two  solutions 
is  the  essence  of  the  forms  programming  by  example  system  for  non-programmers. 
The  constant  visual  feedback  the  user  receives  while  constructing  a  program  is 
further  enhanced  by  combining  it  with  the  use  of  examples.  Non-programmers  are  no 
longer  excluded  from  the  programming  process. 

The  next  section  reviews  the  two  systems  which  motivated  this  work.  Irt  the 
third  section  of  this  paper,  the  design  of  the  forms  programming  system  is  presehted. 
First,  an  overview  of  the  forms  folder  model  is  given.  A  brief  background  oh  the 
administrative  features  of  the  forms  programming  system  is  included.  The  next  three 
subsections  describe  the  folder  model  in  detail.  This  includes  a  discussion  of  the  pro¬ 
gramming  constructs  that  are  used  in  the  forms  programming  system.  Finally,  the 
folder  model  is  reviewed  once  again  to  place  the  previous  discussions  in  context. 

The  final  section  presents  the  conclusions  and  briefly  discusses  a  few  exten¬ 
sions  to  the  forms  programming  system. 

2.  EXISTING  APPROACHES 

A  number  of  forms  programming  systems  have  been  created  in  the  past  few 
years,  some  as  part  of  an  office  information  system  [deJo80,  ZI008I,  Zloo77, 
SLTC82,  EINu80]  and  some  as  systems  by  themselves  [Embl80,  RoSh82,  LuYa81]. 
Programming  by  example,  in  the  context  that  it  is  being  used  here,  has  been  used  in  a 
number  of  different  programming  environments  [Smit76,  Curr78,  LiHe80,  Lieb82, 
AtSi82],  a  few  of  which  relate  to  office  systems. 


1  See  Section  3.1. 
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2.1.  The  SmaliStar  System 

Dan  Halbert  has  added  programming  by  example  to  the  SmaliStar  prototype  of 
the  Xerox  Star  office  information  system.  The  Star  workstation  provides  facilities  for 
electronic  document  creation,  data  processing,  filing,  mailing,  and  printing.  It  is 
Intended  for  office  professionals  who  create,  analyze,  and  distribute  information. 

Halbert's  system  [Halb81]  provides  simple  command  recording,  program  generali¬ 
zation,  and  an  iteration  mechanism.  The  recorded  program  is  automatically  translated 
Into  Cusp,  the  application-specific  programming  language  normally  used  to  program 
the  system.  Cusp  has  an  English-like  syntax,  but  it  still  has  many  of  the  characteris¬ 
tics  of  conventional  programming  languages. 

For  systems  with  a  strong  visual  orientation,  like  the  Star,  programming  by  exam¬ 
ple  seems  to  be  a  natural  and  practical  method  of  writing  programs.  The  ideas  in 
Halbert's  system  on  programming  by  example  were  the  inspiration  for  the  programming 
by  example  part  of  the  work  presented  in  this  paper.  The  application  is  different,  but 
the  implementation  environment  is  essentially  the  same  as  in  SmaliStar.  Both  systems 
are  targeted  at  the  non-programming  office  worker. 

2.2.  TLA  and  Fong's  Model 

TLA  [HoggBI,  NIerBI,  Tsic82,  TRGN82]  was  created  as  a  tool  to  introduce 
automatic  forms  processing  into  an  electronic  forms  management  system.  It  provides 
a  facility  for  automating  office  procedures  that  can  be  used  by  office  workers  with  a 
minimum  of  training.  An  emphasis  is  placed  on  providing  familiar  concepts  and  a  highly 
uniform  interface. 

[Fong83]  has  extended  the  model  used  by  TLA.  She  distinguishes  between 
one-use  and  multi-use  forms,  organizes  the  forms  in  a  procedure,  and  establishes  four 
distinct  stages  to  the  specification  of  an  automated  procedure. 

The  model  used  in  TLA  and  the  folder  model  proposed  by  Fong  were  the  basis  for 
the  folder-oriented  model  of  forms  processing  used  in  this  paper.  All  three  models  are 
targeted  at  allowing  non-programming  office  workers  to  specify  automated  forms- 
processing  procedures. 

3.  THE  FOLDER  MODEL 

3.1.  The  Model 

In  the  rest  of  this  section  the  folder  model  of  forms  processing  will  be  discussed 
in  detail,  but  first  an  overview  of  the  model  is  needed.  This  will  allow  subsequent  dis¬ 
cussions  to  be  placed  in  their  intended  context. 

There  are  four  distinct  stages  to  specifying  a  forms  procedure:  collection, 
action,  deadline,  and  disposal.  In  the  collection  stage,  the  forms  required  by  the  pro¬ 
cedure  are  gathered.  Not  just  any  form  Is  eligible  for  membership  in  this  collection  of 
required  forms.  There  may  be  relationships  between  the  forms  or  restrictions  on  a 
form's  field  values  that  must  be  satisfied.  The  type  of  form  must  also  be  specified. 
It  is  possible  that  a  given  form  may  be  sharable  between  different  procedures  or 
even  between  different  instances  of  the  same  procedure.  This  too  must  be  indi¬ 
cated. 

Having  successfully  assembled  a  folder  of  forms,  the  user  proceeds  to  the 
action  stage.  He  can  manipulate  the  forms  he  has  assembled,  create  new  ones,  or 
retrieve  Information  external  to  the  procedure.  I  ho  bulk  of  the  programming  takes 
place  in  this  stage. 

Next,  the  user  takes  care  of  deadline  actions.  What  happens  to  a  folder  of 
forms  that  can't  proceed  because  It  is  missing  a  form,  or  forms,  from  its  required  set? 
If  nothing  is  done,  the  folder  may  end  up  'wailing  for  godot.' 
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Finally,  after  all  the  processing  is  completed,  the  forms  are  filed  in  their  proper 
place.  Of  course,  the  forms  are  disposed  of  on  an  individual  basis. ^  They  can  be 
placed  in  the  filing  cabinet,  thrown  away  in  the  garbage  can,  or  sent  to  someone  else. 

It  is  important  to  redlizg  that  the  above  process  models  both  the  manual  and 
automated  systems.  The  only  difference  between  the  two  is  the  amount  of  process¬ 
ing  that  is  done  by  the  system.  In  an  automated  system,  the  gathering  of  the  fofffIS, 
the  enforcement  of  deadlines,  and  the  disposing  of  the  forms  are  performed  by  the 
system.  In  a  manual  system  these  tasks  are  performed  by  an  office  worker. 

3.2.  Administrative  Features 

The  forms  programming  system  described  in  this  paper  is  part  of  the  prototype 
message  management  system  (MMS)  being  developed  at  the  University  of  Toronto. 
Other  subsystems  which  it  includes  are  a  communication  base  design  system  used  to 
create  and  define  message  types  [Woo83]  and  a  simple-to-use  system  interface 
[Lee83]. 

In  a  programming  by  example  system,  the  user  programs  in  the  interface  of  the 
system.  The  statements  in  his  program  are  the  same  as  the  normal  commands.  Of 
course,  additional  commands  are  necessary  to  give  the  user  a  fully  functional  pro¬ 
gramming  system.  There  are  a  number  of  commands  from  the  MMS  interface  that  the 
user  will  need  to  use  when  programming.  The  MOVE,  COPY,  and  UNDO  commands  are 
of  most  relevance  to  this  paper.  A  complete  description  of  their  use  can  be  found  in 
[Lee83]. 

System  forms  are  used  to  provide  a  visual  interface  for  arguments  to  some 
commands  and  for  the  specification  of  constraints  when  needed  in  the  programming 
process.  For  example,  each  form  in  a  procedure's  collection  has  certain  selection  cri¬ 
teria  associated  with  it.  The  system  form  interface  is  used  to  specify  those  criteria. 
Pop-up  menus  are  used  as  well.  A  pop-up  menu  contains  the  commands  that  are 
applicable  to  the  selected  target. 

When  the  user  wishes  to  start  a  programming  session,  he  must  switch  over  to 
the  forms  programming  interface.  A  forms  procedure  is  stored  in  a  procedure  file 
icon.  When  the  user  has  completed  the  four  stages  of  a  forms  procedure  definition, 
he  uses  the  CLOSE  command  to  exit.  If  the  user  wishes  to  stop  a  programming  ses¬ 
sion  before  he  has  actually  completed  the  procedure,  he  uses  the  suspend  command 
from  the  programming  menu.  A  suspended  procedure  waits  for  the  user  to  complete  it. 
He  uses  the  continue  command  to  pick  up  exactly  where  he  left  off.  The  continue 
command  can  be  used  even  when  a  procedure  is  not  suspended.  In  this  case,  the 
user  may  wish  to  add  more  actions  to  his  program.  Closing  an  incomplete  procedure 
(as  determined  by  the  system)  has  the  same  result  as  suspending  the  procedure.  A 
suspended  procedure  is  not  active  as  an  automatic  procedure  nor  can  it  be  invoked 
manually. 

Error  correction  during  program  recording  is  done,  for  the  most  part,  using  the 
same  facilities  as  in  the  rest  of  the  system.  Typing  errors  are  corrected  as  in  the 
rest  of  the  MMS;  due  to  the  nature  of  programming  by  example,  however,  there  will 
be  little  opportunity  to  commit  many.  The  UNDO  command  reverses  the  effects  of  the 
previous  operation.  By  using  the  to  here  command  with  the  UNDO  command,  a  number 
Q-^  Qp0j"g-^jQPg  can  be  reversed  at  once.  The  start  over  command  can  be  selected 
from  the  programming  menu  for  those  cases  when  it  is  best  not  to  try  and  salvage 
any  of  the  existing  program.  Commands  like  UNDO,  to  here,  and  start  over  are  not 
recordable,  so  the  user  does  not  need  to  worry  about  their  affects  on  the  program. 

2  Iteration,  when  Introduced,  will  facilitate  the  handling  of  the  case  where  more  than  one  form  Is  placed  in 
the  same  location. 

3  They  are  completely  analogous  to  option  sheets  In  the  Star  [SIKH82]. 
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The  user  may  wish  to  review  part  of  the  program,  or  the  whole  program,  as  he  is 
programming.  The  play  back  command  allows  him  to  watch  the  program  execute  step 
by  step  from  the  beginning  of  the  procedure.  The  same  example  he  is  using  to 
specify  the  procedure  is  used  .  It  is  analogous  to  making  a  tape  recording  and  then 
playing  it  back. 

Automatic  procedures  become  active  when  the  user  closes  a  complete  pro¬ 
cedure  file.  Active  automatic  procedures  are  invoked  by  the  system.  A  suspended 
procedure,  even  if  it  is  complete,  cannot  be  invoked  by  the  system  or  the  user.  Thus, 
a  user  can  define  a  complete  procedure  and  not  invoke  it  until  a  future  point  in  time 
by  suspending  it.  A  procedure  which  does  not  have  a  collection,  however,  can  only 
be  invoked  manually.  The  do  It  command  accomplishes  this  task. 

3.3.  Specifying  the  Collection 

3.3.1.  Overview 

The  purpose  of  the  cdllectidh  Stage  Is  to  assemble  the  set  of  forms  that  are 
needed  by  the  procedure.  There  are  a  number  of  tasks  that  must  be  done  for  each 
form  that  is  included  in  the  set.  First,  the  user  must  find  an  example  form  to  work 
with.  The  next  step  is  to  specify  the  exact  criteria  that  he  used  when  selecting  the 
form.  Did  the  values  of  any  of  the  fields  have  to  satisfy  certain  constraints?  How  is 
this  form  related  to  the  other  forms  already  in  the  set? 

The  third  task  is  to  indicate  how  the  form  is  to  be  used.  If  the  same  form  has 
the  potential  to  be  included  in  other  procedures'  collections,  should  it  be  sharable 
among  them  all?  It  might  only  be  sharable  among  a  specific  subset  of  the  procedures. 
For  example,  consider  the  multi-copy  forms  that  one  must  frequently  complete.  Each 
copy,  in  conjunction  with  the  additional  forms  required  by  each  department,  will  ini¬ 
tiate  a  different  procedure,  even  if  it  is  only  to  file  it  away.  This  is  a  classic  example 
of  a  sharable  form. 

This  sharable  distinction  can  be  carried  a  step  further.  Until  now,  the  question 
of  sharing  a  form  arose  only  when  the  user  placed  the  same  form  type  with  non¬ 
exclusive  constraints  in  different  procedures.  The  forms  within  a  procedure,  how¬ 
ever,  have  the  potential  of  being  sharable  across  the  instantiations  of  the  procedure. 
For  example,  three  instantiations  of  a  procedure  may  be  waiting  for  the  same  form.  If 
such  a  form  arrives,  can  all  three  instantiations  use  it  or  can  only  one  use  it?  Again, 
the  user  must  specify  this.  Consider  a  procedure  which  matches  purchase  orders  and 
delivery  confirmations  by  customer  name  and  item  only.  It  a  particular  customer  has 
three  purchase  orders  pending  for  the  same  quantity  of  an  item,  a  single  delivery 
confirmation  for  one  of  the  three  orders  can  only  be  used  once. 

These  are  the  steps  that  must  be  performed  for  each  form  that  is  included  in  a 
procedure's  collection.  The  remainder  of  this  section  will  describe  the  underlying 
issues  for  each  of  these  steps. 

3.3.2.  Membership  in  the  Collection 

Consider  the  status  of  a  form  after  it  has  been  processed  and  archived;  it  is  no 
different  than  an  address  entry  in  a  customer  information  data  base.  They  both  are 
retrieved  in  the  same  way;  they  are  retrieved  when  they  are  needed. 

When  a  form  arrives  at  the  user's  mailbox,  it  must  seek  out  a  folder  to  process 
It.  The  form  was  not  scluMlulod  to  arrive;  tlm  .system  Irrarned  of  Ih;  oxlr.lr)n(:o  only 
tlu’ough  Its  arrival.  The  address  entry,  however,  is  dineroiit.  It  exists  and  can  be 
.iccessed  at  any  time.  The  procedure  will  seek  it  out  when  it  requires  it. 

Recall  that  the  collection  of  forms  required  by  the  folder  must  be  assembled  as 
the  first  stage  in  specifying  a  folder.  The  above  distinction  can  be  used  as  the  cri¬ 
terion  for  deciding  which  forms  to  include  in  this  collection.  Only  those  forms  which 


-  6  - 


seek  out  a  folder  to  process  themselves  are  candidates.  The  form  seeks  out  a  folder 
by  announcing  its  arrival;  the  system  then  dispatches  it  to  the  proper  folder(s). 

3.3.3.  Semantics  of  the  In  Mail-Tray  and  Other  Designated  Sources 

A  form  arriving  at  a  mail-tray  will  be  dispatched  to  its  appropriate  folder(s). 
There  are  four  cases  which  must  be  handled: 

(i)  the  form  will  instantiate  a  folder; 

(ii)  the  form  belongs  to  an  instantiated  folder; 

(iii)  the  form  potentially  belongs  to  a  folder  which  has  not  been  instan¬ 
tiated; 

(iv)  the  form  is  not  used  by  any  existing  folder. 

The  first  and  second  cases  are  quite  straightforward.  The  third  case  might  be 
handled  by  having  these  forms  dispatched  to  a  special  file.  When  a  new  folder  is 
instantiated,  this  file  would  be  checked  for  forms  needed  by  the  new  folder.  Combina¬ 
tions  of  the  first  three  cases  are  possible;  this  depends  on  how  many  folders  the 
form  can  be  placed  in.  The  fourth  case  needs  no  special  attention.  These  forms  are 
left  in  the  in  mail-tray  for  the  user  to  handle.  If  he  wishes,  he  can  have  them  placed 
in  designated  files  using  his  own  criteria. 

As  described  above,  the  form  looks  for  the  folder,  not  the  folder  for  the  form. 
The  presence  of  a  form  in  the  in  mail-tray  requires  a  folder  to  be  found  to  process  it. 
The  presence  of  a  folder  does  not  require  a  form  to  exist  to  be  processed.  By  adopt¬ 
ing  this  view,  the  semantics  associated  with  the  in  mail-tray  for  dispatching  a  form 
are  an  implicit  part  of  the  model. 

Until  now,  it  was  assumed  that  the  first  form  placed  in  the  collection  will  instan¬ 
tiate  a  procedure.  This,  however,  is  an  unnecessary  restriction.  The  user  should  be 
able  to  indicate  which  form(s)  can  instantiate  a  procedure,  regardless  of  the  order 
that  they  were  placed  in  the  collection  This  is  accomplished  by  including  a  simple 
yes/no  option  for  the  instantiate  entry  in  the  form  selection  criteria  system  form. 
The  details  of  this  system  form  are  presented  in  section  3.3.5. 

3.3.4.  Sharable  Data 

Throughout  this  section,  information  has  been  distinguished  on  the  basis  of 
whether  it  must  seek  the  folder  out  or  the  folder  must  seek  it  out.  Consider  the 
latter  case  first.  When  a  folder  needs  to  retrieve  specific  information,  it  uses  the 
search  template  associated  with  the  repository  containing  the  desired  information.^ 
The  only  action  performed  is  a  read;  if  the  folder  needs  to  change  such  archived 
information,  it  must  instantiate  an  update  form.  Thus,  information  accessed  using  a 
search  template  is  inherently  sharable.  There  is  no  need  for  the  programmer  to  desig¬ 
nate  it  as  such. 

The  question  of  sharing  the  forms  belonging  to  a  folder's  collection  requires  two 
cases  to  be  considered:  sharing  between  folders  and  sharing  between  instantiations 
of  a  folder. 

If  the  programmer  uses  the  same  form  in  more  than  one  folder,  how  should  the 
system  handle  it?  The  selection  criteria  system  form,  to  be  described  later,  contains 
an  entry  listing  the  folders  the  form  is  used  in  as  a  boolean  expression.  And  is  the 
default,  meaning  that  the  form  is  shared;  or  means  that  the  first  folder  to  complete  is 
the  only  one  that  can  use  the  form.  In  the  latter  case,  !he  user  has  an  option  to 
specify  the  order  that  the  folders  should  be  tried  in.  Of  course,  ands  and  ors  can  be 
mixed,  implying  the  obvious  interpretation.  They  would  be  piesented  to  the  user  in 
two  groups  joined  by  an  and  or  an  or;  for  example,  ((folder  w  and  folder  x)  and 


4  this  facility  will  be  described  in  the  action  stage. 
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(folder  y  or  folder  z))  means  that  the  form  in  question  is  sharable  between  folder  w, 
folder  X,  and  the  first  folder  to  complete  between  folder  y  and  folder  z. 

Although  quite  complex  expressions  can  be  made,  the  user  will  most  probably 
designate  the  form  as  either  sharable  or  non-sharable  over  all  the  folders  it  is  com¬ 
mon  to. 

It  should  be  emphasized  that  this  whole  discussion  only  applies  to  folders  that 
share  a  common  form.  This  will  most  probably  be  the  exception  rather  than  the  rule. 

In  the  case  of  sharing  a  form  between  folders,  the  concern  is  over  the  same 
type  of  form  being  shared.  Not  every  instance  of  the  form  in  question,  however, 
would  necessarily  be  used  in  all  its  potential  locations.  Nevertheless,  the  system  is 
told  how  to  proceed  in  event  that  it  could  be.  A  similar  situation  holds  true  for  sharing 
a  form  between  instantiations  of  a  folder.  Since  it  is  impossible  to  determine  which 
forms  will  be  shared  until  run-time,  the  question  must  be  decided  in  advance.  Indeed, 
all  except  the  form  which  instantiated  the  folder  are  candidates.  This  is  handled  by 
including  a  sharable/non-sharable  option  on  the  selection  criteria  system  form. 

3,3.5.  Activation  Conditions  and  the  Selection  Criteria  System  Form 

Until  now,  attention  has  been  focused  on  the  type  of  information  that  a  folder 
uses  and  how  this  Information  is  accessed.  In  this  section,  a  facility  that  allows  the 
programmer  to  place  conditions  on  the  activation  of  a  folder  Is  described.  The  only 
condition  in  force  now  is  that  each  of  the  forms  specified  in  the  collection  must  arrive 
before  the  folder  can  carry  on.  The  programmer  has  no  way  of  specifying  relation¬ 
ships  between  these  forms  and  placing  restrictions  on  field  values  as  of  yet. 

The  form  selection  criteria  command,  presented  as  a  system  form  (figure  1 ),  is 
used  to  specify  these  activation  conditions.  After  the  programmer  selects  a  form, 
the  criteria  system  form  is  automatically  produced.  Each  form  in  a  folder's  collection 
has  one.  This  system  form  provides  a  convenient  static  representation  for  the  col¬ 
lection  stage.  All  the  relevant  information  on  each  form  in  the  collection  is  contained 
In  each  form's  selection  criteria  system  form.  More  specifically,  it  contains  the 
source  for  the  form,  the  instantiate  status,  the  field  restrictions,  the  relationships  to 
the  other  forms  In  the  collection,  the  other  folders  the  form  is  used  in,  and  the  form's 
sharable  status. 

Consider  an  example  set  of  events.  Suppose  the  user  finds  an  example  of  the 
form  required  for  a  particular  procedure  in  his  in  mail-tray  and  places  it  in  the  folder. 
The  system  responds  by  displaying  the  selection  criteria  system  form.  The  entry  for 
the  source  already  has  a  picture  of  the  in  mail-tray  in  it.  The  source  attribute  indi¬ 
cates  the  location  of  the  possible  sources  for  this  form.  Usually,  the  in  mail-tray  will 
be  the  sole  source,  however,  additional  sources  can  be  specified.  The  user  may  indi¬ 
cate  that  this  form  can  instantiate  the  procedure  by  setting  the  instantiate  entry  to 
'yes.'  The  first  form  placed  in  the  collection  is  the  only  form  that  has  the  instantiate 
entry  set  to  'yes'  by  default.  Next,  the  user  specifies  the  field  value  restrictions,  if 
there  are  any.  He  does  this  by  forming  predicates  in  the  augmented  calculator  inter¬ 
face  using  the  example  form.  As  he  finishes  each  predicate,  it  appears  in  the  proper 
field  of  the  form  template  on  the  system  form. 

Form  relationships  are  specified  by  forming  predicates  using  the  examples  from 
both  forms.  The  system  form  contains  a  template  of  each  of  the  other  forms  in  the 
collection  that  this  form  is  related  to.  These  templates  are  added  dynamically.  The 
predicate  appears  in  the  proper  field  of  this  form's  template  as  before,  except  the 
field  name  is  substituted  for  the  exampie  element  used  in  the  form. 

Finally,  the  user  can  set  the  two  options  governing  the  use  of  the  form.  The 
sharable  attribute  requires  a  simple  yes/no  choice.  Recall  that  this  applies  to  the 
sharing  of  the  form  between  instantiations  of  the  procedure.  As  explained  earlier,  a 
boolean  expression  is  presented  if  the  form  can  be  used  in  other  procedures.  The 
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Figure  1*  The  form  selection  criteria  system  form 
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user  can  alter  the  form's  sharable  status  between  procedures,  as  well  as  Indicating 
an  order  for  the  procedures  to  be  tried  in. 

3.4.  Actions 

The  action  stage  is  where  the  user  can  manipulate  the  forms  he  has  assembled 
in  the  collection,  create  new  ones,  and  retrieve  additional  information.  This  is  the 
stage  where  the  user  requires  the  basic  ingredients  of  a  conventional  programming 
language. 

Any  program  can  be  constructed  out  of  suitable  combinations  of  step-by-step 
(sequential)  instructions,  binary  decisions  (conditionals),  and  loops  [B6Ja66].  The 
great  variety  of  structures  that  a  particular  programming  language  may  provide  do  not 
add  to  the  power  of  the  language.  Facilities  for  realizing  these  three  basic  struc¬ 
tures  are  presented  in  the  rest  of  this  section. 

3.4.1.  Generalization 

In  section  3.2  an  overview  of  the  basic  commands  used  in  the  MMS  interface,  as 
well  as  a  description  of  the  basic  programming  mechanism,  was  given.  With  these 
facilities,  a  user  could  start  writing  some  programs.  The  problem  is  that  the  programs 
will  always  perform  exactly  the  same  actions  on  the  same  objects  and  accept  no 
Input  from  an  office  worker  using  the  program.  The  user  has  no  facility  to  generalize 
the  program;  everything  is  treated  as  a  constant.  Under  these  circumstances,  the 
user  can  only  write  fairly  uninteresting  programs.  Generalization  supplies  the  user 
with  a  way  to  distinguish  between  constants  and  parameters.  There  are  two  ques¬ 
tions  to  be  dealt  with  when  considering  the  generalization  issue.  First,  what  should 
be  generalized,  and  second,  when  should  it  be  generalized? 

A  pop-up  menu  is  used  to  present  a  list  of  possible  generalizations  to  the  user, 
as  in  the  SmallStar  system  [HalbSI].  Three  kinds  of  generalizations  are  possible: 

same  name 
same  field  value 
ask  for  user  input 

Same  name  is  used  to  generalize  a  selected  icon.  For  instance,  if  the  user 
wishes  to  have  the  Exchange  Rate  file  chosen  every  time  the  program  is  run,  he 
selects  the  Exchange  Rate  file  and  then  specifies  the  same  name  generalization. 
Thus,  when  the  program  is  run,  the  system  searches  for  a  file  named  Exchange  Rate 
(i.e.,  a  file  with  the  same  name). 

The  same  field  value  generalization  refers  to  the  value  of  the  selected  form 
field  at  run  time.  For  example,  if  a  customer  name  field  is  selected,  then  the  same 
field  value  generalization  will  select  the  value  of  the  customer  name  field  at  the  time 
the  program  is  run. 

The  ask  for  user  Input  generalization  is  the  simplest  kind  of  generalization, 
since  it  retains  the  fewest  characteristics  of  the  specific  datum  used  in  the  exam¬ 
ple.  The  user's  input  must  satisfy  the  constraints  of  the  form  field  for  which  he  is 
supplying  a  value.*  For  example,  if  the  user  is  asked  to  input  a  date,  the  value  he 
inputs  must  be  a  valid  date.  When  the  program  is  run,  a  prompt  will  appear  requesting 
information  from  the  user;  once  it  has  been  entered  correctly,  the  program  continues. 

The  ask  for  user  input  generalization  should  include  the  following  two  capabili¬ 
ties.  First,  the  programmer  sfiould  bo  able  lo  supply  the  prompt  I  hat  the  offic(!  worker 
sees  when  using  the  program.  Second,  the  programmer  may  want  to  give  the  office 
worker  a  choice  in  the  type  of  value  to  input. 


5  These  constraints  will  have  been  specified  using  the  message  type  design  subsystem  [Woo83]. 
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A  user  input  system  form  allows  the  programmer  to  specify  both  of  these 
options.  If  the  programmer  does  not  wish  to  change  anything,  the  system  will  use  a 
standard  prompt  (which  is  displayed  on  the  system  form)  and  no  choice  will  be 
allowed  in  the  user  input.  The  programmer  can  specify  the  number  of  choices  a  user 
will  be  given,  as  well  as  a  separate  prompt  for  each  of  them.  When  the  programmer  Is 
finished  with  the  system  form,  he  must  supply  examples  and  the  intended  actions  for 
each  possible  user  input. 

There  are  a  number  of  opportunities  during  and  after  the  programming  of  a  pro- 
cedure  for  specifying  generalization.®  In  the  forms  programming  system,  generaliza¬ 
tion  during  program  recording  is  used.  In  addition  to  being  the  quickest  method,  it  is 
probably  the  easiest  for  non-programmers  to  learn.  Generalizing  after  the  program  is 
written  is  essentially  a  form  of  program  editing.  These  methods  could  be  available  as 
part  of  a  program  editor. 

The  problem  with  generalizing  during  program  recording  is  that  the  user  must 
remember  to  generalize  each  datum.  This  is  taken  cafe  of  by  using  a  separate, 
automatic  pop-up  menu.  Whenever  the  user  selects  a  datum,  a  pop-up  generalization 
menu  appears  (figure  2).  The  user  is  required  to  choose  one  of  the  items  from  the 
menu  before  continuing.  Experiments  must  be  conducted  with  the  user  community  to 
see  if  these  constant  reminders  are  a  nuisance.  Perhaps  giving  the  user  the  ability 
to  choose  would  be  the  best  solution.  This  permits  the  user  to  take  advantage  of  the 
reminder  facility  when  he  is  first  learning  how  to  use  the  system  and  to  turn  it  off 
when  he  becomes  proficient. 


same  name 
same  field  value 
ask  for  user  Input 
no  generalization 

Figure  2.  The  generalization  pop-up  menu. 


3.4.2.  Matching  Entries  in  the  Data  Base 

When  programming  a  form,  there  is  a  frequent  need  to  retrieve  information  from 
various  files  that  are  maintained  in  the  office.  Most  of  these  retrievals  use  informa¬ 
tion  from  other  fields  on  the  form  to  match  an  entry  in  a  given  file  to  obtain  a  value 
for  a  particular  form  field.  What  is  needed  is  a  simple  interface  for  the  user  to 
specify  these  matches  while  staying  within  the  programming  by  example  framework. 
The  following  method  is  used: 

For  each  file  there  is  a  general  search  template.  When  the  user 
selects  a  file,  he  is  presented  with  a  portion  of  the  contents  of  the 
file  and  a  search  template. 

The  user  then  selects  the  search  template;  for  each  possible  field 
that  can  be  matched  in  the  file,  there  will  be  a  field  that  can  be  filled 
in  on  the  search  template. 

The  user  fills  in  the  fields  on  the  search  template  by  selecting  the 
appropriate  form  field,  specifying  a  generalization,  copying  it,  and  set¬ 
ting  it  down  in  the  search  template,  or  by  inputting  it  directly  and 
specifying  the  ask  for  user  input  generalization. 


6  A  complete  discussion  of  the  issues 


involved  can  be  found  in  [Prop83]. 
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The  user  does  not  have  to  fill  in  all  possible  fields.  The  match  com¬ 
mand,  which  appears  on  the  search  template,  executes  the  search. 
The  system  will  present  those  entries  (tuples)  that  match  the  com¬ 
pleted  fields  of  the  search  template.  The  user  can  then  specify  more 
fields  to  be  matched,  but  only  those  fields  that  have  not  already  been 
filled  in.  Of  course,  the  UNDO  command  can  restore  the  world  to  its 
previous  state  if  he  does  not  like  what  he  did. 

When  more  than  one  entry  matches  the  search  template,  the  user  is  presented 
with  a  list  of  all  the  matching  entries.  The  user  either  picks  one  of  the  entries  from 
the  list  or,  if  possible,  specifies  more  fields  of  the  search  template  and  executes 
another  match.  A  similar  capability  should  be  available  for  the  office  workers  using 
the  program.  This  means  that  incomplete  patterns  can  be  specified  without  reper¬ 
cussions.  An  exact  match  command  also  appears  on  the  search  template  for  those 
cases  where  the  user  only  wants  the  system  to  find  exact  matches. 

The  matching  facility  described  here  appears  to  be  sufficient  for  its  intended 
use.  If  the  need  is  demonstrated,  it  can  easily  be  extended  to  accept  predicates  in 
the  search  template.  The  specification  of  predicates  is  the  subject  of  the  next  sec¬ 
tion. 

3.4.3.  Arithmetic  Expressions  and  Predicates 

The  calculator  icon  in  the  Star  [SIKH82]  provides  a  facility  for  performing  arith¬ 
metic  calculations.  It  is  modeled  after  the  familiar  pocket  calculator.  The  only  differ¬ 
ence  between  them  is  that  instead  of  having  a  single  one-line  display,  as  in  a  pocket 
calculator,  it  has  three  one-line  displays  (figure  3).  One  display  contains  the  current 
entry,  the  second  the  expression  as  it  is  being  built,  and  the  third  the  result  of  the 
expression. 

The  calculator  interface,  to  be  used  here,  is  an  effective  tool  for  specifying 
arithmetic  expressions  [HalbSI].  The  operations  performed  with  the  calculator  are 
used  to  build  up  an  expression.  When  the  user  is  finished  constructing  the  expres¬ 
sion,  he  can  MOVE  the  result  to  the  desired  location.  Of  course,  he  must  generalize 
the  operands  of  the  expression,  as  well  as  the  result.  Just  as  he  would  in  the  rest  of 
the  program.  The  completed  expression  could  also  be  used  in  the  static  representa¬ 
tion  of  the  program. 

Halbert's  [HalbSI]  suggestion  of  using  an  extension  of  the  calculator  interface 
for  specifying  predicates  is  adopted  for  the  forms  programming  system.  The 
calculator's  menu  of  arithmetic  operators  is  augmented  with  the  relational  and 
boolean  operators.  The  user  builds  up  an  expression  exactly  as  he  does  with  a  regu¬ 
lar  calculator.  For  example,  suppose  the  user  is  in  the  collection  stage  and  wishes  to 
specify  that  the  customer  name  field  from  two  forms  must  match.  He  would  proceed 
as  follows:  select  the  customer  name  field  from  the  first  form,  generalize  with  the 
same  field  value  generalization,  COPY  the  selected  field  and  move  it  to  the 
calculator's  entry  window,  push  the  [enT^rl  key,  push  the  N  key,  and  then  follow  the 
same  procedure  for  the  customer  name  field  of  the  second  form,  with  the  exception 
of  the  last  action.  When  the  user  finishes  the  expression,  it  is  inserted  in  the  form 
selection  criteria  system  form. 

The  major  advantage  of  such  a  scheme  is  its  relative  simplicity— the  user  is  not 
required  to  learn  and  remember  a  new  syntax  and  its  associated  semantics.  Most 
people  know  how  to  operate  an  electronic  calculator  and  consequently,  should  have 
no  problem  extending  their  conceptual  model  to  include  the  relational  and  boolean 
operators. 
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Figure  3.  A  Star-like  calculator. 


3.4.4.  Conditionals 

A  facility  for  programming  conditionals  is  an  essential  element  of  a  forms  pro¬ 
gramming  system.  There  are  two  aspects  to  the  specification  of  conditionals:  the 
predicate  and  the  action  clauses.  A  method  for  specifying  predicates  was  described 
in  the  previous  section. 

A  basic  problem  is  encountered  when  trying  to  mesh  conditionals  with  a  pro¬ 
gramming  by  example  framework.  Given  the  state  of  the  world,  a  predicate  is  either 
true  or  false;  when  does  one  record  the  actions  associated  with  the  opposite  state 
of  the  world? 

In  this  section,  a  simple,  elegant  technique  for  specifying  all  the  possible  forms 
of  the  conditional  is  presented.  This  technique  allows  the  user  to  record  the  alter¬ 
nate  actions  during  the  same  programming  pass  without  losing  the  programming  by 

example  spirit. 

Four  distinct,  but  not  mutually  exclusive,  forms  of  the  conditional  can  be  identi¬ 
fied  (figure  4).  The  simplest  form  of  the  conditional  is  the  conditional  execution  of  a 
single  statement;  there  is  no  alternate  action.  The  next  level  of  complexity  is  choos¬ 
ing  between  two  statements;  an  alternate  action  is  specified.  The  nested  form  of 
the  conditional  occurs  when  a  component  statement  of  one  of  the  branches  contains 
a  conditional.  Finally,  there  is  the  more  general  cons^»■uction  which  causes  exactly 
one  of  a  group  of  statements  to  be  executed  (i.e.,  the  statement  associated  with  the 
first  predicate  that  evaluates  to  true).  This  type  of  statement  is  usually  called  the 
case  statement  or  the  choose  statement.  Of  course,  the  case  statement  can  be  simu¬ 
lated  with  only  the  if-then-else  construct,  and  similarly,  the  if-then-else  construct 
can  be  simulated  with  the  case  statement.  Nevertheless,  the  simplicity  of  the  case 
statement  as  opposed  to  its  simulated  counterpart  warrants  its  inclusion  as  a 

separate  construct. 
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if  predi 
then  actioni 

*  if  predi 

then  actioni 
else  action2 

if  predi 
then  if  pred2 

then  actioni 
else  action2 
else  if  pred3 

then  action3 
else  action4 


^  choose 

predi :  actioni  ; 
pred2:  action2; 


Otherwise:  action  n; 

Figure  4.  Possible  forms  of  the  conditional. 


Now  that  the  desired  capabilities  of  the  conditional  facility  have  been  described, 
they  must  be  integrated  into  the  programming  by  example  forms  system. 

Consider  the  four  forms  of  the  conditional  as  shown  in  figure  4.  Anyone  who  has 
had  exposure  to  a  programming  language  will  have  no  problem  understanding  these 
constructs.  But  how  would  they  be  explained  to  a  student  learning  his  first  program¬ 
ming  language?  Obviously,  with  a  picture  that  describes  the  flow  of  control,  which 
more  times  than  not  is  with  a  flowchart  (figure  5),  It  would  make  sense  then,  to 
exploit  a  pictorial  representation  that  is  easy  to  understand  in  the  programming  by 
example  interface.  Consider  the  following  sequence  of  events.  The  user  starts  to 
build  a  predicate--this  could  be  detected  implicitly  by  noting  when  a  boolean  or  rela¬ 
tional  operator  is  selected  or  by  requiring  the  user  to  explicitly  state  his  intention. 
The  system  immediately  begins  constructing  a  picture  of  the  user's  actions  (figure 
6). 

The  predicate  happens  to  evaluate  to  true.  He  then  proceeds  to  program  the 
actions  associated  with  this  branch.  The  system's  updated  diagram  is  shown  in  fig¬ 
ure  7.  The  user  now  wishes  to  specify  the  alternate  action.  This  can  be  accom¬ 
plished  by  simply  moving  the  cursor  to  the  '?'  and  selecting  it.  At  this  point  the  sys¬ 
tem  will  also  undo  (but  not  erase)  those  actions  specified  by  the  first  branch  of  the 
conditional.  The  system  is  now  ready  for  the  user  to  change  the  world  so  the  alter¬ 
nate  branch  can  be  recorded.  The  user  will  know  when  he  has  successfully  altered 
the  state  of  the  world,  since  the  system  will  respond  by  drawing  in  an  action  box  for 
this  branch  of  the  predicate.^ 

The  final  point  to  consider  is  how  to  end  a  conditional.  Upon  ending  a  condi¬ 
tional,  the  system  restores  the  state  of  the  world  to  its  pre-conditional  state  and 

7  Note,  the  action  can  be  a  predicate,  and  the  system  will  change  the  shape  of  the  box  upon  detecting 
this. 
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Figure  5.  Flowchart  diagrams  for  the  four 
forms  of  the  conditional. 
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Figure  6.  The  diagram  after  a  predicate 
has  been  detected. 
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Figure  7.  The  diagram  after  recording  the 
initial  branch  of  the  predicate. 


then  executes  the  conditional.  This  is  done  to  retain  the  original  example.  Future 
actions  may  depend  on  the  original  example's  inter-field  dependencies,  which  were 
destroyed  by  the  previous  changes  to  the  state  of  the  world.  When  dealing  with 
nested  conditionals,  a  new  dimension  is  added  to  the  problem.  Now  the  user  may 
want  to  end  a  focal  conditional  or  a  global  conditional.  A  local  conditional  is  a  condi¬ 
tional  of  depth  one,  while  a  global  conditional  is  a  conditional  of  depth  greater  than 
one  (figure  8). 

This  problem  is  solved  by  introducing  a  single  new  command  called  end  condi¬ 
tional.  When  the  user  wishes  to  end  a  particular  conditional,  he  simply  moves  the 
cursor  to  the  appropriate  predicate  in  the  flow  diagram,  selects  it,  and  issues  the 
end  conditional  command.  The  beauty  of  this  method  is  that  the  user  can  end  a  huge 
nested  conditional  with  merely  one  command.  Upon  receiving  the  end  conditional 
command  the  system  will  restore  the  world  to  the  appropriate  state. 

The  system  will  remind  the  user  about  unspecified  branches  of  conditionals 
when  he  finishes  programming  the  procedure.  Since  most  of  the  unspecified 
braiiches  will  be  null  alternate  brahches,  the  system  could  ask  the  user,  when  he 
ends  such  a  conditional,  if  the  unspecified  alternate  branch  was  intentionally  left 
unsp'ecified  or  If  It  will  be  completed  at  a  later  time.  This  way  the  system  would  not 
remind  the  user  to  complete  a  branch  which  he  does  not  want  completed.  Experi¬ 
ments  must  be  conducted  to  see  if  such  a  dialogue  is  more  of  a  nuisance  than  a  help. 

The  flowchart  diagram  for  a  nested  conditional  can  become  unwieldy  quite 
quickly.  This  can  be  avoided  by  having  both  local  and  global  flowchart  diagrams.  The 
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Figure  8.  An  example  of  local  and  global 
conditionals. 


global  diagram  would  give  the  overall  structure  of  the  complete  conditional.  The  local 
diagram  would  give  the  detailed  structure  of  the  particular  conditional  that  the  user 
is  working  on.®  With  both  of  these  flowchart  diagrams,  the  user  has  both  the  neces¬ 
sary  detail  and  the  general  structure  available  to  help  him  navigate  through  the  con¬ 
ditional. 

A  separate  facility  is  also  used  for  the  case  statement  [Prop83].  Its  operation 
is  similar  to  the  conditional  facility  presented  here. 

3.4.5.  Loops 

Most  programs  require  a  set  of  actions  to  be  performed  repeatedly,  changing 
something  slightly  each  time  the  set  of  actions  is  repeated.  The  only  way  a  user  can 
do  this  under  the  present  circumstances  is  to  laboriously  repeat  the  same  set  of 
actions  each  time  they  are  to  be  performed.  If  a  looping  construct  was  available,  the 
user  could  give  the  set  of  actions  once  and  specify  the  set  of  data  over  which  they 
are  to  be  performed. 

There  are  three  aspects  that  must  be  specified  when  defining  a  loop  structure: 
the  set  of  actions  that  are  repeated,  the  set  of  data  that  the  actions  are  performed 
on,  and  the  stopping  criterion.  These  aspects  are  specified  differently  depending  on 
the  type  of  loop  being  used  (i.e.,  loops  that  test  a  condition  to  determine  if  the  loop 
body  should  be  repeated  {while  loops  and  until  loops)  or  loops  that  iterate  over  a  set 
of  data  {for  loops)).  With  the  former  type,  the  set  of  data  is  implicit  in  the  actions  of 
the  loop  body,  while  the  stopping  criterion  is  explicitly  specified.  With  the  latter 
type,  the  set  of  data  is  explicitly  specified,  while  the  stopping  criterion  is  always 
'when  the  set  is  finished.' 

While  loops  are  the  simplest  type  of  loop  for  the  user  to  construct.  The  loop  is 
created  by  selecting  the  loop-while  command  from  the  programming  pop-up  menu. 
The  system  constructs  a  picture  of  the  user's  actions  (figure  9)®  as  it  does  with 

8  This  is  analogous  to  navigating  a  driving  trip,  where  a  global  map  shows  the  complete  route,  and  various  lo¬ 
cal  maps  show  particular  regions  of  the  route  In  detail. 

9  The  complete  flow  diagram  of  the  loop  is  drawn  from  the  start.  The  user's  current  position  in  the  diagram  Is 


-  17  - 


conditionals.  The  system  then  waits  for  the  user  to  specify  the  stopping  condition 
for  the  loop.  He  does  this  by  constructing  a  predicate  (by  example)  with  the  aug¬ 
mented  calculator.  Since  the  loop  is  executed  only  while  the  condition  is  true,  the 
predicate  must  evaluate  to  true  in  order  for  the  user  to  proceed. Next,  the  user 
specifies  the  loop  body  (i.e.,  the  set  of  actions  that  are  to  be  repeated).  He  ends  the 
loop  by  selecting  the  end  loop  command  from  the  pop-up  menu.  The  end  loop  com¬ 
mand  is  used  to  end  all  loops. 


loop-while  condition 


I 

I 

I 


Figure  9.  The  loop-while  diagram  before 
the  specification  of  the  loop. 


Until  loops  are  the  same  as  while  loops  with  one  exception:  the  loop  body  is 
executed  before  the  condition  is  tested.  This  has  two  implications:  first,  the  user 
specifies  the  stopping  condition  after  specifying  the  loop  body,  and  second,  the 
predicate  used  for  the  stopping  condition  does  not  have  to  evaluate  to  true.  Until 
loops  are  created  by  selecting  the  loop-until  command  from  the  pop-up  menu. 

For  loops  are  slightly  more  complex  for  two  reasons.  First,  the  set  of  data  over 
which  the  loop  Is  repeated,  the  iteration  set,  must  be  constructed.  Second,  the 
notion  of  jumping  back  in  the  program  text  is  hard  for  non-programmers  to  under¬ 
stand  [HalbSI],  Although  while  loops  also  have  this  last  characteristic,  it  is  easier 
for  the  user  to  understand  in  this  context,  since  a  predicate  is  explicitly  controlling 
the  flow  of  control.  This  is  reinforced  by  the  flow  diagram  that  is  displayed  by  the 
system.  For  loops,  on  the  other  hand,  iterate  until  they  have  finished  going  through 
the  set  of  data;  the  flow  of  control  is  implicit  in  the  semantics  of  the  for  loop.  Both  of 
these  problems  are  addressed  by  the  use  of  a  novel  diagram  to  illustrate  the  for 
loop. 


Indicated  by  the  flashing  segment  of  the  diagram.  Completed  portions  are  displayed  In  reverse  video. 

10  If  It  evaluates  to  false,  the  user  can  temporarily  change  the  world  (I.e.,  the  example  he  Is  working  with) 
as  he  does  with  conditionals.  When  he  Is  finished  specifying  the  loop,  the  world  returns  to  Its  pre-loop  state, 
as  If  the  predicate  evaluated  to  false  and  the  loop  was  not  executed. 
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Specifying  an  iteration  set  is  similar  to  specifying  a  generalization.  In  the  latter 
case,  a  single  object  Is  generalized,  while  in  the  former,  a  set  of  objects  is  general¬ 
ized.  In  the  worst  case,  the  user  must  supply  the  whole  iteration  set.  When  there  is 
a  specific  criterion  relating  all  the  elements  of  the  iteration  set,  the  user  can  con¬ 
struct  a  predicate  to  determine  membership  in  the  iteration  set.  When  there  is  a 
specific  ordering  to  the  elements,  as  with  numbers,  the  user  can  specify  the  end¬ 
points  of  the  range.  The  fourth  type  of  iteration  set  generalization  uses  all  icons,  of 
the  same  type  as  the  example  icon,  that  are  in  the  same  container  [Halb81].  For 
example,  if  the  user  selects  one  of  the  forms  in  the  procedure  folder,  this  type  of 
generalization  will  include  all  the  forms  in  the  folder  in  the  iteration  set.  This  is  useful 
for  placing  all  the  forms  in  the  same  location  during  the  disposal  stage.  Similarly,  If 
the  user  selects  one  item  from  a  list  of  matching  entries,  this  generalization  will 
include  all  the  matching  entries  in  the  iteration  set. 

As  with  normal  generalization,  a  pop-up  menu  is  used  to  present  the  list  of  pos¬ 
sible  iteration  set  generalizations  to  the  user  (figure  10).  The  iteration  set  is  com- 
Duted  at  run-time  for  all  the  generalizations. 


specify  the  entire  set 
build  a  predicate 
range 

same  type  in  same  container 

Figure  10.  The  iteration  set  generaliza¬ 
tion  pop-up  menu. 


The  user  starts  a  for  loop  by  selecting  the  loop-for-each  command  from  the 
menu;  the  system  responds  by  displaying  the  loop-for-each  diagram  and  the  Itera¬ 
tion  set  generalization  pop-up  menu.  Assume  the  user  chooses  to  build  a  predicate. 
When  he  completes  the  predicate,  all  the  objects  satisfying  it  are  placed  in  the  itera¬ 
tion  set  (figure  11).  If  there  are  no  objects  that  can  be  placed  in  the  Iteration  set 
and  the  user  has  not  made  any  errors  in  specifying  the  generalization,  he  must 
change  the  state  of  the  world  so  some  object  can  be  placed  in  the  iteration  set.  The 
world  is  changed  and  restored  in  exactly  the  same  way  as  it  was  in  previous 
instances.  As  before,  the  actions  performed  in  the  course  of  changing  the  world  are 
not  recorded  as  part  of  the  program.  The  user  also  has  the  option  of  indicating 
whether  future  occurrences  of  an  empty  iteration  set  are  deemed  to  be  errors  or 
not.  If  they  are,  the  system  will  suspend  the  offending  instantiation  and  notify  the 
user. 

Figure  1 1  contains  a  pictorial  representation  of  the  objects  making  up  the  itera¬ 
tion  set.  With  this  diagram,  the  user  knows  the  exact  contents  of  the  iteration  set. 
He  then  records  the  loop  body  using  the  first  member  of  the  iteration  set  as  an  exam¬ 
ple.  When  he  is  done,  he  selects  the  end  loop  command,  which  ends  the  loop  and 
executes  the  loop  body  for  the  other  members  of  the  iteration  set.  The  system 
diagram  illustrates  the  execution  seguence  by  moving  the  loop  body  (see  figure  11) 
across  the  iteration  set.  This  method  of  representing  a  for  loop  changes  the  para¬ 
digm  of  Jumping  back  in  the  program  text  to  a  paradigm  of  applying  the  loop  body  to 
each  member  in  the  iteration  set. 
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Figure  11.  The  loop-for-each  diagram 
after  the  Iteration  set  has 
been  specified. 


3.5.  Deadlines  and  Disposal 

An  automatic  procedure  does  not  become  impatient.  An  instantiated  folder  could 
wait  forever  for  the  rest  of  its  collection  to  arrive.  Thus,  it  is  Important  to  provide  a 
facility  for  specifying  deadlines. 

The  forms  programming  system  was  designed  to  handle  the  routine  processing 
of  forms.  Exceptions  are  left  for  the  user  to  process,  however,  the  user  should  be 
made  aware  of  the  occurrence  of  an  exception.  He  will  handle  the  exception 
appropriately  and  then  let  the  system  resume.  When  an  exception  becomes  routine, 
he  can  write  a  new  forms  procedure  to  handle  it. 

A  deadline  is  an  exception.  The  user  expected  the  procedure's  full  complement 
of  forms  to  arrive  within  a  reasonable  time.  The  possible  permutations  of  missing 
forms  grows  rapidly  with  the  number  of  forms  in  the  collection.  The  actions  to  be 
taken  for  each  possible  combination  are  left  to  the  user  to  perform  explicitly.  The 
system  only  needs  to  inform  the  user  that  the  folder's  collection  has  not  completed 
within  the  specified  time. 

The  user  specifies  a  deadline  for  a  folder's  collection  by  indicating  the  amount 
of  time  it  has  to  complete  and  the  action(s)  to  be  taken  when  the  deadline  is  passed. 
Time  Is  specified  in  one  of  three  ways  [Fong83]:  (i)  absolute  time  using  the  year- 
month-day-hour  notation,  (ii)  relative  time  such  as  'one  week  from  today,'  or  (ill)  vari¬ 
able  time  as  a  function  of  the  folder,  for  example,  'one  week  after  the  instantiation  of 
the  folder.'  The  user  can  specify  any  action  that  is  possible  within  the  programming 
system.  For  example,  he  could  send  a  message  to  himself  or  to  another  person  on 
the  system.  Common  actions  that  relate  to  the  folder  itself  are  selected  from  a  pop¬ 
up  menu.  Actions  that  appear  in  the  menu  include:  throw  the  folder  in  the  garbage 
can,  suspend  further  processing,  and  send  the  folder  to  someone  else.  The  exact 
composition  of  the  menu  will  be  determined  by  the  users. 

Disposing  of  the  forms  of  a  procedure  is  the  simplest  of  the  four  stages.  The 
user  must  indicate  a  destination  for  each  form  in  the  collection  and  for  any  forms  that 
were  instantiated  during  the  action  stage.  This  is  accomplished  by  performing  the 
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action  on  the  example  forms  used  in  the  procedure.  For  example,  one  form  might  be 
filed  away,  another  thrown  away,  and  a  third  sent  to  someone  else.  As  with  the  other 
stages,  the  user  can  specify  any  action  that  is  possible  within  the  programming  sys¬ 
tem  providing  the  semantics  of  the  action  make  sense.  For  example,  if  a  subset  of 
the  forms  are  to  be  placed  in  the  same  location,  the  user  can  use  the  loop-for-each 
iteration  construct  to  avoid  repeating  the  same  action  over  and  over  again.  On  the 
other  hand,  the  usor  cannot  instantiate  a  new  form  in  the  disposal  stage. 

3.6.  The  Model  Revisited 

The  user  starts  off  by  creating  a  folder  and  gathering  the  forms  required  for  the 
folder  to  complete.  The  first  form  that  the  user  moves  into  the  folder  will  be  the  one 
which  will  instantiate  the  folder,  unless  he  specifies  otherwise.  Forms  are  usually 
related  to  one  another,  but  they  need  not  be.  If  they  are  not.  It  is  just  one  less  con¬ 
dition  to  satisfy.  All  forms  are  not  required  to  be  related  to  a  single  unique  form.  For 
instance,  the  instantiating  form  A  might  be  related  to  form  B  and  form  B  might  be 
related  to  form  C. 

The  user  retrieves  an  example  form  from  the  source  where  he  expects  to  find  it, 
usually  the  in  mail-tray.  The  system  handles  the  dispatching  of  forms  to  their  folders. 

Each  form  has  a  form  selection  criteria  system  form  associated  with  it.  The  pri¬ 
mary  purpose  of  this  system  form  is  for  the  programmer  to  specify  the  form  relation¬ 
ships  and  the  field  value  restrictions.  It  is  also  used  to  control  the  usage  of  the  form. 
He  can  indicate  whether  the  form  is  able  to  instantiate  the  procedure.  He  can  also 
specify  how  the  form  is  shared  between  folders  and  in  what  order  these  folders  are 
executed.  If  he  is  content  with  the  defaults  (i.e.,  sharable  and  executed  in  the  same 
order  as  they  were  programmed  in)  he  does  not  have  to  change  a  thing.  Of  course, 
this  control  information  is  only  necessary  for  those  forms  that  can  be  shared.  There 
is  also  an  attribute  on  the  system  form  for  sharing  a  form  between  instantiations  of  a 
folder.  This  must  be  present  for  each  form  in  the  folder. 

In  the  action  stage,  the  user  specifies  exactly  what  he  wants  the  procedure  to 
do  by  going  through  an  example.  The  programming  constructs  placed  at  his  disposal 
give  him  the  full  power  of  a  conventional  programming  language.  The  commands  from 
the  MMS  interface  provide  the  basic  set  of  sequential  instructions.  The  augmented 
calculator  interface  provides  the  facility  for  specifying  arithmetic  expressions  and 
predicates.  The  user  parameterizes  his  program  with  the  generalization  commands.  A 
special  facility  for  matching  entries  in  data  files  is  also  available.  Conditionals  and 
loops  are  constructed  within  the  programming  by  example  framework. 

Before  completing  the  procedure,  the  user  creates  a  contingency  plan  in  case 
the  procedure's  collection  is  not  assembled  by  the  deadline.  Most  of  the  time  the 
plan  will  consist  of  a  message  being  sent  to  the  user  informing  him  of  the  situation.  If 
a  plan  is  not  specified,  the  procedure  could  be  waiting  for  a  form  that  will  never 
arrive. 

Finally,  the  user  specifies  what  is  to  be  done  with  the  set  of  forms.  No  new 
commands  are  necessary  here.  He  might  file  them  away  in  the  filing  cabinet,  move 
them  to  the  garbage  can,  or  send  them  to  someone  else.  Of  course,  each  form  is  han¬ 
dled  individually.  If  the  same  fate  is  to  befall  them  all,  then  iteration  can  be  used. 

When  the  user  is  finished,  the  system  will  present  him  with  a  left-to-do  reminder. 
It  contains  a  list  of  items  that  must  be  taken  care  of  before  the  program  can  run  and 
a  second  list  of  potential  trouble  spots.  If  both  lists  are  empty,  the  reminder  is  not 
presented.  The  user  can  view  the  left-to-do  reminder  list  at  times  other  than  at  the 
end  of  a  programming  session  by  explicitly  requesting  it. 


-  21  - 


4.  CONCLUDING  REMARKS 

In  this  paper,  a  system  for  writing  forms-processing  procedures  in  an  office 
environment  has  been  designed.  The  intended  users  are  non-programming  office  per¬ 
sonnel,  such  as  secretaries,  administrative  support  persons,  and  managers.  The  sys¬ 
tem  makes  use  of  the  folder  model  of  forms  processing  and  the  programming  by 
example  methodology.  The  folder  model  structures  a  forms  processing  procedure 
from  the  office  worker's  view.  The  programming  by  example  methodology  gives  the 
non-programming  office  worker  access  to  his  forms  programming  system;  it  is  no 
longer  necessary  for  him  to  wait  for  an  available  system  expert  to  attend  to  his 
needs.  Functionally,  the  user  is  given  the  same  power  as  a  conventional  programming 
language.  The  three  basic  ingredients  of  a  programming  language  are  at  his  disposal: 
sequential  instructions,  conditionals,  and  loops. 

The  forms  programming  system  is  designed  to  handle  the  routine  processing  of 
forms.  It  is  recognized  that  an  office  must  also  handle  the  many  unexpected  cir¬ 
cumstances  that  occur,  however,  the  processing  of  these  exceptions  is  left  for  the 
user.  The  system  will  alert  the  user  and  expect  him  to  intervene,  if  he  wishes,  he 
can  have  the  system  resume  after  he  has  finished  processing  the  exception. 

Programming  by  example  is  a  general  technique  that  allows  ordinary  users  to 
program  their  own  systems.^  ^  It  is  a  methodology;  it  is  not  a  particular  implementation 
of  a  set  of  programming  constructs.  There  are  two  reasons  why  it  is  especially  suit¬ 
able  for  non-programmers.  First,  the  user  writes  his  programs  in  tiie  user  interface  of 
the  system  that  he  already  knows.  Second,  he  programs  using  an  actual  example, 
yet  he  can  apply  the  resulting  program  to  other  data.  In  conventional  programming 
languages,  he  must  think  in  abstract  terms  while  writing  his  program. 

The  type  of  implementation  environment  used  is  also  an  important  feature.  Pro¬ 
gramming  by  example  relies  quite  heavily  on  giving  the  user  immediate  visual  feed¬ 
back  to  his  actions.  This  assures  the  user  that  his  actions  were  performed  as 
intended.  Not  all  systems  have  this  heavy  visual  orientation.  An  easy-to-use  system 
interface  is  another  requirement,  since  programming  by  example  uses  the  command 
language  of  the  system  interface.  Again,  a  graphical  interface,  where  'seeing  and 
pointing'  is  the  method  of  interaction  instead  of  'remembering  and  typing,'  is  the 
preferable  environment. 

In  conclusion,  the  techniques  of  programming  by  example  and  the  folder  model  of 
forms  processing  procedures  resulted  in  a  successful  combination.  Non-programmers 
are  no  longer  excluded  from  writing  their  own  forms-processing  procedures.  The  ulti¬ 
mate  test,  however,  will  be  when  non-programming  office  workers  actually  use  the 
system. 

4.1.  Extensions 

Under  the  present  circumstances,  the  form  selection  criteria  system  form  is  the 
only  static  representation  used  throughout  the  programming  of  a  procedure,  and  it  is 
only  used  for  the  collection  stage.  The  programming  constructs  that  the  user  uses  in 
the  action  stage  are  represented  by  their  affects  on  the  state  of  the  world. 
Although  this  does  not  stop  the  user  from  writing  programs,  recording  the  user's 
actions  in  an  intermediate  language  has  many  potential  benefits.  First,  operations 
that  are  used  in  conjunction  with  the  to  here  command  can  be  specified  more  pre¬ 
cisely.  Second,  the  user  may  wish  to  edit  or  correct  his  program  once  it  has  been 
recorded.  Third,  seeing  the  correspondence  between  his  actions  and  the  statements 
generated  in  the  intermediate  language  will  improve  the  user's  programming  ability. 
Finally,  an  intermediate  language  will  be  useful  in  situations  where  the  user  finds  it 
necessary  to  have  a  system  expert  take  over  the  task  of  writing  a  particular 


11  This  point  has  not  been  substantiated  with  actual  tests  on  potential  users  as  yet. 
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program.  There  are  a  number  of  different  options  to  consider  when  choosing  a  static 
representation.  The  differences  between  them  iie  predominately  in  the  level  of  detail 
contained  in  the  representation  and  the  degree  to  which  the  semantics  of  the  opera¬ 
tions  are  expressed  in  the  representation.  A  discussion  of  the  various  options  is 
presented  in  [Prop83]. 

When  a  user  has  finished  writing  a  program  by  example,  he  has  also  done  an 
example  of  the  program.  This  should  make  the  possibility  of  writing  an  incorrect  pro¬ 
gram  unlikely.  Nevertheless,  there  are  instances  where  the  user  may  need  to  edit  a 
program.  He  may  wish  to  change  a  recorded  program,  or  he  may  discover  that  he 
failed  to  anticipate  some  of  the  cases  which  the  example  case  did  not  cover.  What¬ 
ever  the  reason,  the  mechanism  for  editing  a  program  must  be  as  simple  and  straight¬ 
forward  as  the  programming  by  example  system.  A  brief  discussion  of  some  possible 
editing  paradigms  can  be  found  in  [Prop83]. 
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ATIIKNIANS*.  A  f^rosopograpliy  of  Ancient  Athens 
Rased  on  the  Meritt  File 

J.  'Praill  c'.nd  D.  Tsichritzis 

.Abstract 

The  gCcU  of  the  Athenians  project  is  the  preparation  and  publication  of  data 
on  persons  of  ancient  Athens  from  the  eeirliest  records  in  the  seventh  century 
B.C.  unti*  the  decline  of  our  sou-^ces  in  the  fourth  century  after  Christ.  It  is 
based  on  the  unpublished  file  of  Attic  prosopography  'which  has  been  created 
emd  ampUfied  by  Professor  B.D.  Me'ritL  and  his  associates  at  the  Institute  for 
Advanced  Study,  Princeton,  during  the  past  half  century,  a  file  which  now 
comprises  well  over  one  hundred  thousand  entries.  The  project  utilizes  a  rela¬ 
tional  dci  a  base  management  system  originally  developed  by  the  Computer  Sys¬ 
tems  Reseerch  Group  of  the  University  of  Toronto  and  running  under  UNIX. 
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1.  Introduction 

The  Meritt  card  index  of  the  names  of  the  people  of  ancient  Athens  is  the 
product  of  50  years  (a  period  contemporaneous  with  the  modern  phase  of  the 
Agon  Excavations)  of  modern  scholarly  industry.  This  material  was  compiled 
from  a  surprising  abundance  of  written  material,  especially  inscriptions,  which 
survives  in  Attica  and  elsewhere  in  the  Graeco-Roman  world  over  more  than  a 
millennium  from  the  earliest  records  in  the  seventh  century  B.C.  until  the 
decline  of  our  sources  in  the  fourth  and  fifth  centuries  after  Christ.  The  source 
material  comprises  well  over  100,000  index  cards,  each  giving  the  basic  bio- 
grapliical  details,  and  the  references  which  contain  them,  for  ancient  Athenians 
and  other  people  involved  in  the  life  of  a  most  remarkable  city-state  during  an 
extrc.ordinary  period. 

The  information  available,  like  modern  census  data,  lends  itself  to  storage 
and  retrieval  through  a  computer  data  base  system  where  it  can  be  tabulated 
into  headings  someone  (1),  from  some  place  (2),  did  something  (3),  at  a  certain 
date  (4),  as  recorded  in  a  certain  document  (5).  That  person  was  related  in  a 
particular  way  (6)  to  another  person  (7).  These  seven  facts  can  be  entered  from 
the  cards  into  a  relational  data,  base  and  retrieved  through  any  combination  of 
requested  attributes  More  complicated  information  about  any  individual  per¬ 
son,  such  as  several  different  offices  at  different  dates,  or  a  number  of  kin,  or 
several  references  to  the  same  (or  to  additional)  information,  including  a 
number  of  publications  of  the  same  inscription,  papyrus,  vase,  coin,  literary 
text  etc,  can  be  added  through  additional  entries  into  the  main  relation,  or 
through  the  creation  of  a  number  of  relations,  each  containing  a  certain  type  of 
information,  and  each  cross-referenced  to  the  others  by  the  use  of  an  identify¬ 
ing  number. 
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2.  Schema  and  data 

Utilizing  the  data  base  manap,Gment  system  Mistress*  we  resolved,  after 


considerable  discussion  and  experimentation,  to 

break  ATHENIMS  into 

relations,  main,  refp,rence.s,  teats,  a  id  comment.  ( 

as  in  Figure  l) 

MAIN  RELATION 

nun 

greekid 

para 

greek  (15,  2) 

nane 

greek  (15,  2) 

St  at 

short integer 

coda 

short integer 

place 

greek  (18,  2) 

placenod 

integer 

link 

short integer 

kin 

greek  (15,  2) 

id 

char  (16,  1) 

date 

char  (16,  1) 

datefrom 

integer 

dateto 

integer 

REFERENCES  RELATION 

num 

greekid 

ref  no 

short integer 

ref 

char  (18,  1) 

ref line 

integer 

ref tie 

char  ( 1 ,  1) 

class 

short integer 

num 

TEXTS  RELATION 

greekid 

ref  no 

short integer 

item 

short integer 

text 

greek  (60,  25) 

num 

COMMENT  RELATION 

greekid 

item 

short integer 

cooMent 

greek  (60,  15) 

*Mistress  is  s  com-Tiercial  derivative  of  Mf  t3  and  it  iS  being  srapported  and  marketed  by 
Rhodnius. 
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A  relation  is  a  cable  V'ith  a  number  of  defined  headings,  or  attributes,  which 
may  contain  information  in  characters  (character  data  type)  or  in  numbers 
(integer  cha'^acter  type).  We  evaluated  the  optimum  number  of  relations,  the 
related  problems  of  joins  between  relations,  and  the  types  of  information  and 
the  corresponding  data-types  to  be  assigned  to  each  relation.  It  seemed 
expedient  to  place  the  important  biographiced  facts  in  majin  Hence  we  created 
13  attributes  in  this  relation  HAME,  the  most  important  attribute,  listed  alpha¬ 
betically,  tc  wnich  we  assigned  NUM,  a  speciallv  created  id  consisting  of  9  digits 
(for  example  l05765-1-02,  of  which  the  first  6  digits  are  unique  to  the  name)  for 
ease  of  crossreference  across  relations,  then  KIN,  who  is  somebody  related  to 
"name",  and  L'NK,  which  defines  the  relationship  (this  covers  more  than  simply 
relatives,  but  such  relationships  as  co-coin  magistrate,  second  user  of  grave¬ 
stone.  etc).  FL/vCE,  Avhich  is  usually  a  demotic  for  an  Athenian  and  an  ethnic 
for  a  foreigner.  ID  (for  INDENTIFIEK),  which  gives  the  profession  or  office,  some¬ 
times  a  vague  identification  such  as  "in-vase  '  or  even  "unknown",  and  DATE, 
which  is  the  received  date  of  the  ID.  Five  othtr  attributes,  all  numerical,  have 
been  added,  generally  for  data  base  manipulative  purposes:  STAT,  which  gives 
the  social  status  and  type  of  citizenship,  CODE,  which  evaluates  the  type  of 
name,  e.g.  wlit^ther  it  is  broken  or  has  associated  listings  in  the  data  base.  PLA- 
CEMOD,  whic.n  usually  means  phyle,  and  DATEFROM  and  DATETO,  which  are  arbi¬ 
trary  mathematical  conversions  of  DATE.  The  first  kin  in  the  main  relation, 
wherever  it  is  known,  is  the  person’s  patronymic:  for  each  additional  relative 
the  person  receives  an  additional  record  in  the  main  relation  and  the  seventh 
digit  of  the  NUM,  -0-  for  the  first  record,  is  incremented  by  1  (to  -1-,  -2-.  etc.)  for 
each  extra  Idn  record.  Similarly,  an  additional  record  is  made  for  each  addi¬ 
tional  ID  or  e^ctra  date  for  the  same  ID,  and  the  last  two  digits  of  the  NUM  are 
incremented  from  the  -01  of  the  first  record  to  -02,  -03  etc.  Both  upper  and 
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lower  case  are  used,  in  Greek  and  Korrian  fonts,  but  only  upper  case  Greek  (as  in 
the  main  listings  of  Kirchner’s  I ^osopo graphic.  Attwa  appears  in  main  (for 
NAME,  PLACE,  and  KIN).  This  was  done  partly  to  facilitate  searches  and  partly  to 
make  the  data  available  to  scholars  through  terminals  which  might  not  possess 
lower  case  Greek  capability.  We  have  followed  the  APA  convention  as  to  the 
location  of  Greek  letters  on  the  keyboard  as  in  Figure  2. 


ASCII  -  GREEK  KEYBOARD 


Row  1 


Row  2 


Row  3 


Row  4 


ASCII 

DC 

GREEK 

UC 

1234567890“  =  ' 

ascii 

Ic 

1234567890“'''* 

greak 

Ic 

OWERTYUIOPl  ; 

ASCII 

UC 

eOEPTYYIOni’' 

GREEK 

UC 

qwertyuiop  1  \ 

ascii 

ic 

ewcpT^ruionl*' 

greak 

Ic 

ASDFGHJKLj  t 

ASCII 

UC 

AIA^PHpKA''*  ' 

GREEK 

UC 

asdfghjkl  ;  |  < 

ascii 

Ic 

^  » 

graak 

Ic 

ZXCVBNM<>? 

ASCII 

UC 

ZXZDBNMi  •? 

GREEK 

UC 

zxcvbnm,  .  / 

ascii 

Ic 

5  X  5  s  P  •'  M  .  •  / 

graak 

Ic 

Figux«  2 
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It  was  perceived  frcm  the  beginning  that  there  often  were  many  references 
for  a  single  line  of  main,  and  that  this  portion  of  the  data  base  would  accumu¬ 
late  in  future  at  a  far  greater  than  the  main  relation,  i,e.  an  old  text  would  be 
treated  over  ana  over  again  in  new  publications.  It  was  an  obvious  decision  to 
create  a  separate  relation  for  references.  NIJM,  transferred  automatically  in 
the  load  program,  ties  tae  re^'erence  to  the  main  entry.  Each  reference  is  given 
its  own  REPNO,  also  assigned  by  the  computer  and  repeated  in  the  texts  relation 
CO  enable  the  computer  to  p’ck  out  the  appropriate  Greek  TEXT  for  each  refer¬ 
ence.  The  references  chemsedves  are  broken  into  REF  and  REFLINE,  the  former 
entered  according  to  a  stai'dard  table  of  abbreviations.  REFTIE  connects  a 
reference  to  the  preceiiing  cnt.ry,  where  appropriate,  by  =,  when  the  text  is 
identical,  o'*  <,  or  >,  when  the  first  is  superior,  or  inferior,  to  the  second.  CLASS 
offers  a  means  for-  classifying  the  cype  of  document  cited  in  the  reference,  e.g. 
decree,  catalogue,  de'dication  etc.,  and  w  thin  these  larger  classifications, 
decree  of  ti  ibe.  deme,  etc.  Tliis  Jiiurmation  is  coded  in  numerical  form. 

The  texts  I'elation  was  designed  to  give  a  precise  representation  of 
preserved  amd  interpreted  irforniation.  Phonological  variants,  vagaries  of  the 
Attic  alphabet,  s.;gla  marking  epigraphical  restorations,  expansions,  and  correc¬ 
tions,  lexical  errors,  etc.  were  leveled  in  main.  Ail  of  these  are  restored  in  the 
texts  relation  in  the  interest  of  presenting  cs  accurate  a  representation  of  the 
ancient  evidence  as  practicably  possible.  Upper  and  lower  case  Greek,  with  full 
accentuation  and  the  normal  complement  of  epigraphical  and  (eventually,  we 
hope)  papyrological  sigla  are  included.  A  separate  relation  was  deemed  neces¬ 
sary  not  only  tc  avoid  having  lower  case  Greek  in  the  references  relation  (for 
usa  by  terminals  without  Greek),  but  also  in  the  interests  of  economy,  for  just 
as  there  may  be  many  references  for  a  single  entry  in  main,  so  we  may  not  wish 
to  give  a  text  for  each  reference  (for  example,  when  the  texts  for  two  refer- 
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e^iccs  c',rH  ideiiticcl),  or.  on  l.he  other  hand,  many  lines  of  text  may  accompany 
a  single  rt  fere  nee 


The  (:o77n>i(ifd  relation. 


(ionnccled  like^  the  previous  two  relations  to  main 


by  identical  NUM,  was  designed  for  a  dual  purpose:  first,  for  items  too  long  to  be 
elite .'ed  ui  fi>ed  length  attributes  e.g.  long  names,  sich  as  tria  nomina,  ID’s 
needin(:»  ampli  float  ion,  etc.,  ail  of  which  are  marked  in  com  with  the  format  F-, 
for  FULL-;  second,  for  modificrations  of  information  given  in  the  other  relations, 
e.g.,  discussion  of  date,  description  of  an  inscription,  etc.  which  are  meirked  in 
com  -V.OD.  for  -MODIFIED;  third,  for  alternate  readings,  e.g.  ALTDATE,  ALTNAME, 
etc.,  whore  an  alternate,  but  equally  acceptable  reading,  date  exists;  and 
fourth,  for  important  but  occasional  items  not  easily  accomodated  within  the 
devised  scheme,  e.g.  STEM,  AECHON,  APLACE,  PNAME,  KINX,  REFLOC.  STEM  (for 
stemmi)  design.i^d  to  facilitate  the  more  complex  stemmata  derived  from  the 
sjmp'.u,  basic  rela* ions’nip  in  main,  clearly  is  of  great  potential  importance  to 
ATHENlAflo,  ai.d  c-.  separate  relation  for  this  item  is  planned.  ARCHON  serves  the 
rotrievil  c-f  information  dated  by  archon.  The  periods  in  which  the  archon  list 
is  intio’iip’ete  or  insecure  are  our  chief  concern  in  the  inclusion  of  this  item. 
A'-’L^CE  gives  special  attention  to  those  demotics  and  ethnics  which  have  been 
assigned  from  prosopographical  and  other  indirect  information  (marked  with  a 
closing  f-aienthesis  in  main).  PNAME,  PKIN,  PPLACE  mark  phonologically  or 
orthograDhicall}'  significant  forms  which  have  been  leveled  in  main  (but  not  in 
texts').  LINK,  giving  relatives  in  turn  for  a  kin  who  has  been  mentioned  in  the 
main  lela.tion  (e.g.,  the  name  of  the  father  of  the  manumittor  of  the  slave 


whose  name  is  tne  mam  entry),  serves  the  printed  record  more  than  the  data 


base.  RIPT.OC,  the  findspot  of  a  text,  particularly  outside  Athens,  e.g.  Rham- 
rous  or  Hrauron.  has  obvious  significance  for  searches.  The  fifth,  extremely 
importan'.  purpose  of  comment  is  for  what  we  may  designate  as  traditional  dis- 
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cussion.  This  portion  would  not  normally  serve  data  base  purposes  and  should, 
accordingly,  more  appropriately  be  stored  not  in  the  data  base,  but  rather  in 
UNIX  files,  These  portions  of  comment  presumably  will  be  considered  the  true 
"comment",  whereas  it  is  our  intention  to  incorporate  many  of  the  formated 
segments,  e.g,  Fullnarne,  Fullkin,  Fullid,  Altname,  etc.,  into  more  appropriate 
places  in  our  printed  copy.  The  segments  of  corriTnent  are  each  delimited  by  a 
semicolon  so  that  they  may  easily  be  retrieved. 
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3.  Dala  eniry  and  updating 

Through  Die  load  program,  and  other  aids,  we  have  attempted  to  facilitate 
da^a-entry  into  ATHENIANS.  From  the  outset,  however,  it  nriust  be  admitted  that 
the  task  of  the  scholar  entering  data  is  a  very  difficult  one.  We  are  working 
from  a  copy  of  cards  which  are  nearly  all  hand-written,  many  in  very  light  or 
illegible  script.  Furthermore,  the  copy  is  covered  with  e.dditions  and  correc¬ 
tions.  Although  we  have  pre-edited  all  of  the  material  several  times,  many 
questions  and  difficulties  remain.  Some  decisions,  such  as  status,  may  be  post¬ 
poned,  but  even  here  we  have  tried  to  formulate  the  level  of  uncertainty.  The 
greatest  probTims,  howver,  arise  in  the  matter  of  formating.  We  are  using 
coles  as  in  Figures  3  and  4  to  indicate  different  situations.  We  have  compiled  a 
manual  of  50  pages  (many  sections  only  after  long  discussion  and  argument)  of 
instructions  and  tables  for  the  operators  entering  data  from  cards.  Most  of  the 
sections,  particularly  the  lists,  are  on  computer  file,  and  it  is  our  intention  to 
have  all  entry-instructions  available  soon  on  an  "on-line"  h.elp  basis. 

Our  load  program  facilitates  entry  of  data  into  the  four  relations.  It 
as.signs  the  nu.nber  automatically,  and  then  prompts  for  the  various  attributes 
of  each  relation  in  sequence:  main,  refs,  texts,  and  comment.  In  addition  to  the 
normal  facility  of  correction  before  the  prompt  for  the  next  attribute,  the  load 
pr  )gram  allows  the  operator  to  go  back  to  an}'  attribute  before  moving  on  to  the 
next  relation.  There  is  provision  for  the  treatment  of  additional  kin  and  addi¬ 
tional  identifiers  (id)  in  main,  additional  references  in  refs,  and  additional  lines 
in  both  texts  and  ccrnmenl  (conn).  Furthermor  e  the  number  assigned  in  main 
is  incremented  automatically  for  additional  Inn  and  identifiers,  and  is  repeated 
automatically  for  the  successive  relations.  The  line  numbers  (item)  for  addi¬ 
tional  lines  of  text  and  comment  are  also  assigned  automatically,  as  are  the 
reference  numbers  (refno)  in  the  reference  relation. 
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Codes  for  ATHENIANS  Database:  Part  1 


STAT 

QQ  doubt 

assumed 

possible 

-  *  woman 

Athenian  citizen 

1 

2 

3 

0  a  what 

Ath  cit  inside  and  outside  Athens 

4 

5 

6 

St  at? 

Ath  cit  outside  Athens 

7 

8 

9 

100  =  not 

Roman  (if  also  Ath,  supply  units  digits) 

10 

20 

30 

known 

Metic 

61 

62 

63 

Foreigner  (not  Athenian  or  Roman) 

71 

72 

73 

Slave 

81 

82 

83 

Manumitted  slave 

91 

92 

93 

CODE 

(Digits  codes  1,  2,  3,  and  4  can  be  combined  with  codes  10-80) 


-  =  broken 
name 
0  a  what 
code? 


1 

main  name  (no  extras) 

10  main  rest  (alt) 

50 

variant 

2 

main  name  (has  extra) 

20  other  altrest 

60 

ghost 

3 

Roman  auxiliary  name 

30  non-existent? 

70 

bad  rest 

4 

alternate  (6/4)  xat  -) 

40  not  name? 

80 

barbaric  name 

110  go  to  name  given  in  kin  (this  spelling  has  been  levelled) 


LINK 


0 

perhaps  related 

21 

grandson 

56 

manumittor  (f) 

90 

related 

1 

son 

22 

granddaughter 

100 

main  info 

2 

daughter 

23 

grandfather 

61 

slave  (m) 

110 

see  also 

3 

father 

24 

grandmother 

62 

slave  (f) 

120 

same  as? 

4 

mother 

25 

uncle 

65 

manumitted  (m) 

5 

husband 

26 

aunt 

66 

manumitted  ( f ) 

6 

wife 

27 

cousin  (ra) 

7 

brother 

28 

cousin  (f) 

70 

associate 

8 

sister 

29 

f  ather /grandf  ath 

71 

assoc  (related) 

9 

husb/f ather 

30 

root her /gr andmot h 

72 

assoc,  2nd  user 

10 

wife/daughter 

73 

assoc,  later  user 

31 

son-in-law 

75 

assoc  (coin) 

11 

adopted  son 

32 

daughter-in-law 

12 

adop  daughter 

33 

father-in-law 

80 

same  sep  as 

13 

adop  father 

34 

mother-in-law 

81 

same  sep,  related 

14 

adop  mother 

40 

relative 

82 

same  sep,  2nd  use 

17 

adop  brother 

41 

ancestor 

83 

same  sep,  later  use 

18 

adop  sister 

42 

descendant 

85 

same  vase  as 

86 

same  vase,  related 

19 

son/grandson 

51 

owner  (m) 

87 

same  vase ,  2nd  use 

20 

daugh/granddaug 

52 

owner  (f) 

88 

same  vase  later  use 

55 

roanumittor  (m) 

Codes  for  ATHENIANS  Database:  Part  2 


CLASS 


-  =  verse 

10. 

Stone  decrep 

30 

Stone  sepulchral 

2nd  digit: 

11 

boule/demos 

51 

public  monument 

8  =  other 

12 

foreign  (amphict,  imp) 

52 

mar)<er  ( cippus/rupestral ) 

9  *  unident 

13 

tribe 

53 

col,  columella,  labellum 

14 

deme 

54 

stele  (with  ped/no  sculp) 

15 

clerouchy 

55 

stele  (with  anthemion) 

16 

gene/phratry 

56 

stele/lekythos  (sculp) 

17 

club/society 

57 

elaborate  (naiskos  etc) 

20 

Stone  catalogue 

30 

Stone  (other) 

21 

ar chons 

61 

horos 

22 

bouleutai/prytaneis 

62 

theatre  seats 

23 

diaitetai 

63 

letter 

24 

ephebes 

64 

On  a  pythaid  (eph) 

25 

didaskalic/choregic 

65 

Oi  a  pythaid  (others) 

donors /contributors 

27 

thiasotai/orgeones 

30 

Stone  accounts 

20 

Ceramic 

31 

Athena 

71 

ostrakon 

32 

other  deities 

72 

vase,  kalos  name 

33 

manumissions 

73 

vase ,  potter 

34 

p>oletai 

74 

vase,  painter 

35 

naval  lists 

75 

vase ,  owner 

36 

property  leases 

76 

graf f ito/dipinto 

37 

Delian 

AO 

Stone  dedication 

Metal  and  other  materials 

41 

Athenian  state/deme 

81 

bronze  dicast ' s  tablet 

42 

choregic 

82 

cavalry  tablet 

43 

other  agonistic 

83 

bronze  public  monument 

44 

Roman  imperial 

84 

bronze  private  monument 

45 

other  foreign 

85 

coin 

46 

sacerdotal 

86 

lead  curse  tablet 

47 

private 

30 

Literature 

91 

oratory 

92 

history 

93 

philosophy 

94 

drama  and  lyric 

95 

lexicography 

96 

Latin  literature 

97 

papyrus 
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Other  controls,  e.g.  conversion  error  (where  the  wrong  type  of  data  has  been 
entered)  have  been  carried  over  from  the  data  base  system. 

A  sample  data-entry  sequence  from  the  data-base  DELTA  is  incorporated  as 
appendix  A. 

The  computer  program  allows  systematic  checking  for  particular  types  of 
error,  and  we  have  recently  developed  a  series  of  tests,  to  be  applied  to  each 
batch  of  200  or  so  records  as  they  are  completed,  to  help  correct  errors  made 
when  the  material  was  entered. 

Most  of  these  tests  show  up  errors  in  typing,  particularly  errors  which 
which  ae"e  difficult  (in  this  case,  impossible!)  to  see  in  proof-reading,  such  as  not 
remembering  that  a  ,  representing  an  unrestored  name  (of  kin  or  demotic) 
should  be  typed  in  Greek,  in  order  to  allow  computer  searches.  Similarly  the 
delimiter  between  headings  in  the  comment  relation,  the  semicolon,  should 
never  be  typ^ed  in  Greek,  and  a  mistress  program  is  run  to  find  any  semicolons 
typed  in  Greek  and  present  them  for  correction.  Another  typing  error,  easily 
caught  and  corrected  by  computer  program,  is  the  assigning  of  the  coded  "link" 
(1  =  son  of,  2  =  daughter  of  etc)  to  the  wrong  sex  —  a  link  of  1  for  a  feminine 
name  is  clearly  wrong,  and  the  whole  record  can  be  reviewed  and  corrected 
when  the  error  is  presented  for  correction. 

Other  tests  involve  consistency  in  the  form  in  which  certain  types  of 
material  are  entered,  particularly  in  standardization  of  the  references.  Thus 
two  items  of  our  test  program  look  for  Hesperia  references  where  the  "p"  of  the 
page  reference  has  been  omitted  and  Fouilles  de  Delphes  references  where  the 
format  'FdeD  III. 2’  has  been  departed  from.  Consistent  entering  of  references  is 
important  for  use  of  the  computer's  ability  to  search  for,  for  instance,  all  the 
names  listed  in  a  certain  inscription  (if  a  new  publication  of  the  inscription  is 
to  be  added,  or  the  date  modified). 
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still  other  tests  allow  checking  of  the  material  itself.  The  search  for  places 
where  a  person’s  son  is  given  in  the  same  record  with  some  other  information 
about  him  appears  to  be  niorely  a  matter  of  consistency  in  presenting  the 
meterial  (the  kinship  should  have  been  given  a  separate  entry).  But  the  error 
often  shows  up  some  more  serious  mistake,  such  as  the  one  in  the  sample  pro¬ 
gram  here,  where  a  confusion  between  the  father  and  the  son  has  led  to  the 
son’s  identity  and  dates  being  attributed  to  the  father.  The  test  series  allows 
this  error  to  be  checked  and  corrected  immediately,  or,  if  more  extensive 
research  is  required  to  sort  out  a  complication,  the  number  cem  be  noted  and 
returned  to  later.  Similarly,  a  search  for  places  where  the  dates  given  for  a 
father  are  based  on  those  of  his  son’s  period  of  activity  often  shows  not  only 
that  ’’circa"  (to  show  the  inexact  nature  of  such  dates)  is  missing,  but  in  some 
cases  helps  to  discover  that  the  wrong  date  has  been  entered  for  the  record. 
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4.  Searches 

In.  order  to  illustrate  a  few  of  the  basic  benefits  of  our  database  for  the 
study  of  ancient  history  (especially  for  epigraphy,  prosopography,  demogra¬ 
phy),  we  have  compiled  the  following  exercises.  Note  that  all  lines  preceded  by 
an  asterisk  (*)  aire  commands  which  are  typed  into  the  computer;  the  search 
sym-  bols  used  in  match  searches  are  ”  ?  ",  which  represents  a  single  letter 
(any  letter),  and  "  H which  represents  any  number  of  letters  (an  unknown 
number,  including  none  at  all). 

1 

A  common  epigraphical  problem  is  the  restoration  of  broken  names,  where 
only  a  few  letters  of  the  name  remain  legible  in  an  inscription  or  papyrus, 

e  g  I .  )at .  IvC - 1 : 

*  select  unique  name  from  main  where  name  match  •  ?A?NII* '  ; 

name 

AA^IOI 

AA^NIANOI 

AA^NII 

AAiNOE 

AAMNirror 

AAQN 

Requests  for  additional  information  about  all  the  people  bearing  the  ap¬ 
propriate  names  can  be  made  at  the  same  time  (see  the  printout  of  the  4 
rela  tions  in  the  database  for  the  headings  under  which  the  informa¬ 
tion  is  stored): 

*  select  num,  name,  place,  id,  date  from  main 

where  name  match  'TH?©!!!;' 

num  name  place  id  date 


301180-1-01  AHMOKPATHZ  AOMONEYE  unk  c  44/3-22/la 

301185-0-01  AHMOKPATHI  AeMONEYE  thasinothetes  9/8a-13/14p 
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304690-0-01  AHIOTAPOE 
304735-1-01  AHAOAOTOI 
304740-0-01  AHAOAOTOZ 
304745-0-01  AHA04ANHZ 
304745-1-01  AHAO^ANHI 
304745-2-01  AHAOiANHE 


PAAATOE  king 

A-  s«p 

KEIOE  cas 

XOAAPPEYE  dad 

XOAAPPEYE 
XOAAPPEYE 


p  63  or  62a 
lla 

a  446a 
m  IVa 
n  IVa 
B  IVa 


Requests  can  also  be  iTiade  for  combinations  of  name,  patronymic,  and 


deme,  all  in  varying  states  of  prehservation; 


♦  select  name,  kin,  place,  id,  dete  from  main 


where  name  match' *311 AE 'and  kin  match  •  *31A0T0E  *  and  place  match  'BH*'  ; 


name 

kin 

place 

id 

date 

AEINIAE 

KH4IE0A0T0E 

0OYTAAHI 

thesBothetes 

233/2a? 

AEINIAE 

KH4IE0A0T0E 

BOYTAAHE 

unk 

c  336/5a 

2 

More  commonly,  a  historian  will  want  a  list  of  all  the  members  of  a  cer¬ 
tain  deme,  perhaps  requesting  also  their  dates  and  references: 

*  select  unique  name,  id,  date,  ref  from  main,  refs 

where  main.num  =  refs.num 


and  place  =  '♦AYEYE'  and  dateto  <  -350; 


name 

place 

id 

date 

ref 

AEIIOEOE 

♦AYEYE 

unk 

c  365/4a 

II  1544 

AEZieEOE 

♦AYEYE 

unk 

c  433-3e3a 

II  4023 

AEINIAE 

♦AYEYE 

unk 

c  423-393a 

Ag  15  7 

AEINIAE 

♦AYEYE 

unk 

c  423-393a 

II  1743 

Or  all 

those  of  a  certain  profess 

ion  within 

a  certain  period  (including,  in 

this  case,  the  texts  to  '^how  t  o 

what  extent  a  name  is  preserved  in  the  in- 

scription  and  how  much  has  been  restored): 


♦  select  name,  place,  id,  date,  ref,  texts  from  mam,  refs,  texts 
where  main.num  =  refs.num  and  refs.num  =  texts. num 


and  refs.refno  -  texts. refno 


and  id  =  'archon'  and  daiefrom  >  150  and  dateto  <  200; 
name  place  id  date 

ref  text 


AAIAOYXOE 
Ag  15  455 
AAIAOYXOE 
H  34  p97  7 
AAIAOYXOE 
II  2125 


3 


archon 

4iil  iHIpxoktCo$1  Hon*  A<ji^q[0xou1 

archon 


162/3-164/5p 

162/3-164/5p 


[ 4 n J  Hop*  AijiAo  liufxou  1 
MEAITEYE  archon  193/4p 

...  4nl  A9A0UXOU  [MeXiT4u)$  ...  1 


The  database  will  also  serve  a  number  of  demographical  applications. 
One  might,  for  example,  wish  to  find  out  in  what  contexts  in  ancient  Athens 
women  are  mentioned: 

*  select  unique  id  from  main  where  stat  <  0; 
id 

cursed,  ded,  donor,  ergastine,  in-cat,  in-ded,  in-literature, 
in-vase,  maker-peplos,  owner-land,  sep,  sep?,  vowed 

And  how  many  women  do  we  have  information  about  in  proportion  to 
men?  (in  this  case  our  tests  are  run  on  a  group  of  approximately  1100 
records); 

*  select  count  from  main  where  stat  <  0; 

Number  of  Records  =  98 

A  large  proportion  of  our  information  for  women  will  come  from  their 
gravestones; 

*  select  count  from  medn  where  stat  <  0  and  id  =  'sep'; 

Number  of  Records  =  49 


From  those  which  do  not  occur  on  gravestones,  one  might  choose  for 
study  a  particular  group  (e.g.  those  who  are  known  to  have  owned  land): 
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select  name,  place,  id.  date,  ref,  refline,  text 
from  mam,  refs,  texts 

■where  rnain.mim  =  refs.num  and  refs.num  =  texts. num 
and  refs. refno  -  t  exts. refno 

and  stat  <  0  and  id  =  'owner-land'; 
name  place  id  date 

ref  refline  text 


AAMOKAEIA 

H  41  p71 

85 

owner-land  c  130-140p 

KX  Aap6KXeia  (x^P - 1/npAs  tQ  Kry^iaQ  noTopCi^  * 

AAMO 
H  41 

p67 

57 

owner-land  c  130-140p 

KX  Aapcb  4)  Koi  ZuvapdT'ry  ytap  *Kv/ 

AAMO 
H  41 

p67 

57 

owner-land  c  130-140p 

KuXtVri  Kal  ’AypuX?|cyi  np6s  'YptyrTtp 

A  full  report  can  be  made  on  any  combination  of  requests.  We  have  chosen 


to  illustrate  both  a  certain  run  of  some  25  consecutive  records  within  the 
data  base  iATH3.  Ae§-AepK,  ^  selection  of  all  the  women  (only  two,  as  it 
turns  out)  whose  names  appear  in  metrical  inscriptions.  This  is  done  by 
asl-ung  the  computer  the  numbers  ("nums")  of  those  records  where  stat  <  0 
and  class  (the  type  of  inscription)  <  0  (our  code  for  averse  inscription).  A 
special  "report  ’  pi’ogram  is  then  run  on  the  nums  selected,  to  produce: 


300340-0  A-  daughter  of  AHAO^ANHZ  XOAAPPEYZ  (5) 
code:  -1  *tat:  -2 

01  vowed  n  IVa  (360  BC  to  ^40  BC) 

1  ref:  IG  II. 2  4368  line:  3  class:  -47 

♦av6aTpaTols  - J 

vacat 

A-nXoiJxiv'ns  dy^e^vce  XolXapyeus  eU6Ka  J . 

auToO  euyarpis  Al - 1 . 

Aoaip<5tx‘ni  y^P  ^  ^ 

)(etpa  p4yas  <TWT^p  I  I 
vacat 

ini  narlalKOu  IcpiwsJ. 

C  Classnwd  elegiac  coiiplet;  Narte  A I - 1  probably  a  dactyl, 

Wilhelm  suggested  AOPII  (AlwptAos  1 ) ;  Stem  go^o 

AHAOiANHT;  Fullid  made  a  vow  to  Asklepios  to  set  up  a 
statue  to  ♦ANOZTPATOE  for  her  mother's  recovery; 

Idmod  Asklepios; 


— )/ 
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300340-1  A-  daughter  of  AYEIMAXH  XOAAPrEYE  (5) 
coda:  -1  stat:  -2 

01  «»•*•*  iva  (360  BC  to  340  BC) 

1  ref:  IG  II. 2  4368  line;  3  class:  -47 
(see  text  300340-0-01) 


300340-2  A-  associate  of  ♦ANOETPATOE  XCAAPPEYE  (5) 
code:  -1  stat:  -2 

01  •#***♦  m  iva  (360  BC  to  340  AD) 

1  ref:  IG  II. 2  4368  line:  3  class;  -47 
(see  text  300340-0-01) 

C  Kinid  doctor?;  Fulllin)c  in  the  same  dedication  as; 


301380-0  AAMQ  daughter  of  KOPNITOE 
code:  1  stat:  -100 

01  epitaph  la-Ip  (100  BC  to  100  AD) 

1  ref:  IG  II. 2  11040  line:  3  class:  -54 

niyre  xai  etlKoai  >ioOkov  AvanX'fil /aoa  *  ivialuTou$l 

ijiXCTO  ^0  ytoepg  kqt i  1 /cxop^v-n 

Ao>id>  Koyyltrou  SuyAr-np  koI  1 /A«  loyevc  I  (as  1/ 

K<iiXXe  i  nSciv  <paX)/X«y  Ifpiv. 

C  Fullid  twenty-five  year  old  girl; 


301380-1  AAMO  daughter  of  AEIOTENEIA 
code:  1  stat:  -100 
01  ******  la-lp  (100  BC  to  100  AD) 

1  ref:  IG  II. 2  11040  line:  3  class:  -54 
(see  text  301380-0-01) 


Corrections  can  be  made,  either  individually  or  en  masse,  through  the 
update  program  in  the  Mistress  database.  The  database  system  also  lends 
itself  to  testing  and  checking  the  information  entered. 

1 


One  form  of  test  might  be  to  find  out  whether  all  the  people  who  were 
known  to  be  'daughter  of  their  kin  (i.e.,  link  =  8),  have  also  been 
entered  as  women: 


update  main  where  link  =  8  and  stat  >  0, 
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If  there  happen  to  be  no  records  where  this  mistake  occurs,  nothing  will 
be  presented  to  be  updated.  As  it  is,  one  record  does  need  correction,  and 
each  line  is  presented  to  be  changed  if  desired.  In  this  case  the  mistake 
lay  in  not  entering  the  minus  sign  in  "stat",  and  it  is  corrected  by  re¬ 
entering  the  stat  as  ”-2”  instead  of  "2": 

nun:  306120-0-01 
para: 

naaa:  AHMAINETH 
•tat :  2  -2 
coda:  1 

placa:  AIIQNEYE 
placafltod:  7 
link:  2 
kin:  EYHOAir 
id :  sap 
data :  IVa 
datafron:  -400 
datato:  -300 

Number  of  Records  Updated  =  1 

It  is  also  possible  to  use  the  select  program  to  check,  for  example,  that  the 
same  date  is  given  for  the  same  inscription  throughout  the  database. 
Then,  supposing  that  a  new  date  has  been  assigned  to  that  inscription,  the 
update  program  could  be  used  to  change  the  date,  datefrom,  and  date  to 
across  the  board  wherever  that  inscription  is  mentioned: 


*  select  date,  ref  from  main,  refs 

where  main.num  =  refs.num 


eind  ref  =  'Ag  15  23'; 


naM 

date 

ref 

ref line 

AAMIAI 

336/35a 

Ag  15  42 

231 

AEINOKPATHE 

336/5a 

Ag  15  42 

176 

AHMAAHE 

336/5a 

Ag  15  42 

145 

AHMAINETOE 

336/5a 

Ag  15  42 

28 
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Should  it  become  desirable  to  change  the  date  of  this  inscrip:ion 
throughout  the  datebase,  a  single  command  could  be  given,  e.g.: 

♦  update  main,  refs  set  date  to  '330/ la’,  datefrom  to  -330,  dateto  to  -331 

where  main.num  =  refs.num 
and  ref  =  'Ag  15  42’; 

A  minor  error  has  shown  up  through  this  test  —  AAMIAI  should  have  his 
date  changed  to  the  same  form  as  the  others 

♦  update  main  set  date  to  ’336/5a’  where  date  -  '336 /35a’; 

And  to  check  that  it  has  been  done: 

♦  select  unique  name,  date  from  main  where  nam<  'AAMIAI' ; 

name  date 

AAHIAI  336 /5a 
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b.  Concluding  rcmc-'.rks 

The  applicalicn  of  data  base  techniques  to  such  a  body  of  archeological 
material  has  some  very  distinct  advantages:  the  data  may  be  continually 
updated  and  corrected  to  incorporate  the  products  of  scholarly  research  with  a 
minimum  of  effort;  the  information  in  ATTIENIANS  may  be  organized  and 
retrieved  in  a  great  variety  of  ways  both  from  local  and  remote  terminals  to  the 
benefit  of  scholars  in  a  number  of  disciplines;  the  computerized  typesetting 
offers  the  only  economical  means  of  publishing  such  as  work,  and  since  the 
material  will  be  stored  in  computer  form,  future  revised  editions  are 
envisioned.  A'l’HE'vilANS  will  bo  the  first  comprehensive  prosopography  of 
ancient  Athens,  comprising  citizens  at  home  and  abroad,  metics,  visitors,  eind 
slaves,  in  sum,  all  of  the  known  men  and  women  affiliated  with  this  most  dis¬ 
tinguished  city-state  from  the  archaic,  classical,  Hellenistic,  and  Roman 
periods. 

In  the  appendix  we  present  some  sample  data  as  they  appear  in  the  data 
base.  Some  ancient  Athenians  have  a  romaikable  number  of  entries.  For 
example,  the  emperor  Hadrian  has  44  entries  giving  11  pages  of  output!  For 
such  cases  a  hierar  chical  data  base  may  have  been  more  appropriate.  However, 
the  simple  table  structure  and  the  ease  of  querying  of  a  relational  data  base 
offers  many  advantages. 
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SAMPLE  FROM  LOAD  PROGRAM  (DELTA) 


num :  400205-0-01 


*  ♦  * 


refno:  1 


1 

name  ; 

AAIEIAL 

2 

para  ; 

3103 

3 

s  t  a  t ; 

1 

4 

code  ; 

1 

5 

place ; 

AAAIEYE 

6 

placemod ; 

2 

8 

main  kin; 

EVeiAE 

7 

link; 

epi  t 

ersion  error 

*  *  « 

correct ; 

1 

9 

id  ; 

epi  t 

10 

date  ; 

340-317a 

11 

f  rom  ; 

-340 

12 

to ; 

-317 

be 

changed ; 

d 

:  400205-0-01 

1 

name  ; 

AAIEIAE 

2 

para  ; 

3103 

'3 

s tat ; 

1 

4 

code  ; 

1 

5 

place ; 

AAAIEYE 

6 

placemod ; 

2 

7 

link; 

1 

8 

kin; 

EYeiAE 

9 

id ; 

epi  t 

10 

date  ; 

34Q-317a 

11 

datef  rom ; 

-340 

12 

dateto ; 

-317 

>  be 

changed; 

w 

1 

ref  ; 

II  5498 

2 

ref  1 ine ; 

1 

4 

class; 

55 

1  be 

changed : 

1 

ref  ; 

II  5468 

1  be 

changed ; 

d 

num;  400205-0-01 
name;  AAIEIAH 
refno;  1 


1  ref ;  II 

2  ref  line;  1 

3  r  e  f  t  i  e  ; 

4  c lass ;  55 


5468 
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SAMPLE  FROM  LOAD  PROGRAM  (Conf d) 


id  to  be  changed;  w 


text:  Aaiolas/ 

correct?:  Aaiatas/LuStou/'AXaieu^/ /EuBtas/Aaialou/'AXaieu^ 
correct  ? ; 
another  line; 


another  ref ; 

comment:  date  son's  name  added  later;  refloc  Vraona;  pmod  or  7? 
another  line: 

another  id: 

another  kin;  EYIAE 


num :  400205-1  01 

name;  AAIEIAZ 


2 

para  : 

3103 

3 

s  t  a  t ; 

1 

4 

code  : 

1 

5 

place ; 

AAAIEYE 

f 

6 

placemod ; 

2 

8 

kin: 

EYIAE 

7 

link: 

3 

10 

date  ; 

340-3 17a 

11 

£  rom  ; 

-340 

12 

to ; 

-317 

eld 

to  be 

changed : 

8 

kin: 

EYeiAE 

eld 

to  be 

changed : 

d 

num:  400205-l~01 

1 

name  : 

AAIEIAE 

2 

para  : 

3103 

3 

s  t  a  t : 

1 

4 

code  : 

1 

5 

place: 

AAAIEYE 

6 

placemod : 

2 

7 

link  ; 

3 

e 

kin; 

EYeiAE 

9 

id  : 

10 

date  : 

340-317a 

11 

datef  rom : 

-340 

12 

dateto : 

-317 

Jid 

to  be 

changed ; 

w 

1 

1 

ref  : 

II  5468 

2 

ref  1 ine : 

1 

4 

class : 

55 
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SAMPLE  FROM  LOAD  PROGRAM  (Cont’d) 


ref  no:  2 


field  to  be  changed:  d 


num :  400205-1-01 

name:  AAILIAE 
ref  no:  2 

1  ref:  II  5468 

2  refline:  1 

3  ref  t ie : 

^  class:  55 


field  to  be  changed:  w 

text : 


another  ref : 

comment:  check  dateconvert  of  son/father  different? 
another  line: 

another  kin:  exit 


num:  400210-0-01 


next  name : 
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MAIN  RELATION  (part  1) 


num 

para 

name 

stat 

code 

link 

kin 

303780-0-01 

EPENNIOI 

AEZimOE 

11 

2 

1 

HTOAEMAIOE 

303780-0-02 

EPENNIOE 

AEIimOE 

11 

2 

1 

HTOAEMAIOE 

303780-0-03 

EPENNIOE 

AEIimOE 

11 

2 

1 

HTOAEMAIOE 

303780-0-04 

EPENNIOE 

AEZinnoE 

11 

2 

1 

HTOAEMAIOE 

303780-0-05 

EPENNIOE 

AEZimOE 

11 

2 

1 

HTOAEMAIOE 

303780-1-01 

EPENNIOE 

AEZinnoE 

11 

2 

3 

HTOAEMAIOE 

303780-2-01 

EPENNIOE 

AEZinnoE 

11 

2 

3 

AEZIHHOE 

303780-3-01 

EPENNIOE 

AEZinnoE 

11 

2 

3 

EPMONAKTEIA 

303785-0-01 

EPENNIOE 

AEZirmoE 

11 

2 

1 

AEZimOE 

303785-0-02 

EPENNIOE 

AEZinnoE 

11 

2 

3 

AEZirmoE 

303785-0-03 

EPENNIOE 

AEZinnoE 

11 

2 

3 

AEIimOE 

303785-0-04 

EPENNIOE 

AEzinnoE 

11 

2 

3 

AEZinnoi 

303785-0-05 

EPENNIOE 

AEZirmoE 

11 

2 

3 

AEZIHHOE 

303785-1-01 

EPENNIOE 

AEZinnoE 

11 

2 

7 

EPMONAKTEIA 

303785-2-01 

EPENNIOE 

AEZimOE 

11 

2 

7 

HTOAEMAIOE 

303790-0-01 

AEZinnoE 

1 

1 

303795-1-01 

AEZirmoE 

71 

1 

3 

A. . .HIE 

303810-1-01 

AEZinnoE 

71 

1 

3 

APIMNHETOE 

303815-0-01 

AEZIE 

100 

1 

303820-0-01 

AEZIE 

1 

1 

1 

r- 

303825-0-01 

3238 

AEZIE 

1 

1 

1 

AEZIKPATHE 

303830-0-01 

AEZIE 

-71 

1 

303835-0-01 

AEZI4»ANHE 

100 

1 

303840-0-01 

3239 

AEZI^IAOE 

1 

1 

303845-0-01 

3240 

AEZI^QN 

1 

1 

1 

KAAAI^ANHE 

303845-0-02 

3240 

AEZI^ON 

1 

1 

1 

KAAAI4ANHE 

303850-0-01 

3241 

AEZIXAPIE 

1 

1 

1 

♦I- 

303855-1-01 

.3242 

AEZO 

-1 

1 

6 

lEPONYMOE 

303855-2-01 

3242 

AEZn 

-1 

1 

4 

lEPONYMOE 

303855-3-01 

3242 

AEZn 

-1 

1 

4 

lEPOKAEIA 

303860-0-01 

AEZQN 

100 

1 

303865-0-01 

AEZON 

71 

1 

1 

NOYMHNIXOE 

303870-1-01 

S 

AEZON 

100 

1 

3 

AEZIOXOE 

303870-2-01 

S 

AEZQN 

100 

1 

3 

NIKANAPOE 

303875-1-01 

3243 

AEZON 

1 

1 

5 

AYEO 

303875-2-01 

3243 

AEZON 

1 

1 

31 

AYEANAPOE 

303880-0-01 

AEOE 

71 

1 

1 

AHMHTPIOE 

303885-0-01 

AEPAAE 

71 

1 

303890-1-01 

AEPKETHE 

100 

1 

3 

♦lAEAE 

303895-1-01 

3244 

AEPKETHE 

1 

3 

♦lATO 

303900-1-01 

D 

AEPKETHE 

1 

1 

3 

EYHEieHE 

303905-1-01 

3245 

AEPKETHE 

2 

1 

3 

-♦ANHE 

303910-0-01 

AEPKETOE 

100 

1 

303915-0-01 

AEPKETOE 

71 

1 

303920-0-01 

AEPKETOE 

71 

1 

303925-1-01 

AEPKinnOE 

2 

1 

3 

.  .0 . E 
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MAIN  RELATION  (part  2) 


id 

date 

datef rom 

dateto 

placemod 

archon 

a  255/6p 

255 

256 

5 

syngrapheus 

c  269/70p 

259 

280 

5 

strategos? 

267p 

267 

267 

5 

agonothates 

262/3  aut  266/7p 

262 

267 

5 

priast 

a  266/7p 

246 

267 

5 

unk 

c  242/3  /  246/7p 

232 

257 

5 

c  233/4p 

223 

244 

5 

c  233/4p 

223 

244 

5 

dad 

a  266/7p 

246 

267 

5 

gymnaaiarch 

254/5p 

254 

255 

5 

agonothataa 

254/5p 

254 

255 

5 

ty  at  r  aoina  t  ar  cho  a 

254/5p 

254 

255 

5 

nauMchos 

2S4/5p 

254 

255 

5 

a  266/7p 

246 

267 

5 

262/3  aut  266/7p 

262 

267 

5 

boul 

Ilia 

-300 

-200 

2 

unk 

Ip 

1 

100 

unk 

in  IVa 

-400 

-380 

caa 

465/4a? 

-465 

-464 

in-cat 

in  IVa 

-400 

-380 

8 

aap 

m  IVa 

-360 

-340 

2 

aap 

IVa/  pa  p 

-400 

-280 

curaad 

Ilia 

-300 

-200 

klarouch 

p  m  Va 

-450 

-430 

9 

victor 

157/6a 

-157 

-156 

6 

victor 

149/8a 

-149 

-148 

6 

epiatatea-proed 

109/8a 

-109 

-108 

in -cat 

a  m  Ila 

-170 

-150 

10 

a  B  Ila 

-170 

-150 

10 

a  ro  Ila 

-170 

-150 

10 

caa 

465/4a? 

-465 

-464 

aph 

39/8a 

-39 

-38 

unk 

c  158/7a 

-168 

-147 

unk 

c  158/7a 

-168 

-147 

unk 

la 

-100 

-1 

4 

unk 

la 

-100 

-1 

8 

aap 

aet  Rob 

-150 

300 

rular 

c  436a 

-446 

-426 

unk 

a  £  Via 

-520 

-500 

unk 

IVa? 

-400 

-300 

triararch 

336/5-331/Oa 

-336 

-330 

5 

unk 

c  401 /Oa 

-411 

-390 

actor -comic 

in  Ilia 

-300 

-280 

caa 

458a 

-458 

-458 

caa 

458a 

-458 

-458 

unk 

la 

-100 

-1 

place 

EPMEIOE 

EPMEIOE 

EPMEIOE 

EPMEIOE 

EPMEIOE 

EPMEIOE 

EPMEIOE 

EPMEIOE 

EPMEIOE 

EPMEIOE 

EPMEIOE 

EPMEIOE 

EPMEIOE 

EPMEIOE 

EPMEIOE 

nAOeEYE 

HPAKAEQTIE 

EAMIOE 

mnoeoNTiAOE 

EPXIEYE 

OHBAIA 

AIANTIAOE 

OINEIAOE 

OINEIAOE 

RAAAHNEYE 

RAAAHNEYE 

RAAAHNEYE 

T- 


KPORIAHE 

EAEYEINIOE 

BEPOIAIOE? 

MAKEAQN 


EWTTIOE 

♦YAAEIOE 

APREIOE 

APREIOE 

KOeOKIAHE 
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num 

303780-0 

303780-0 

303780-0 

303780-0 

303780-0 

303780-0 

303780-0 

303780-0 

303780-1 

303780-2 

303780-3 

303785-0 

303785-0 

303785-0 

303785-0 

303785-0 

303785-1 

303785-2 

303790-0 

303790-0 

303795-1 

303810-1 

303815-0 

303820-0 

303825-0 

303830-0 

303835-0 

303840-0 

303845-0 

303845-0 

303850-0 

303855-1 

303855-2 

303855-3 

303860-0 

303865-0 

303870-1 

303870-2 

303875-1 

303875-2 

303880-0 

303885-0 

303885-0 

303890-1- 

303895-1- 

303900-1- 

303905-1- 

303905-1- 

303905-1- 

303910-0- 

303910-0- 


REFERENCES  RELATION 


ref  no 

ref 

ref line 

reftie  class 

-01 

1 

II  2931 

2 

41 

-02 

1 

II  3669 

6 

41 

-03 

1 

SNA  Gall  13  8 

92 

-04 

1 

II  3198 

5 

46 

-04 

2 

II  3669 

6 

41 

-05 

1 

II  3670 

6 

46 

-05 

2 

II  3198 

5 

-05 

3 

II  3671 

2 

46 

-01 

1 

II  2245 

14 

24 

-01 

1 

II  3670 

6 

46 

-01 

1 

II  3670 

7 

46 

-01 

1 

II  3670 

7 

46 

-02 

1 

II  2245 

162 

24 

-03 

1 

II  2245 

177 

24 

-04 

1 

II  2245 

303 

24 

-05 

1 

II  2245 

477 

24 

-01 

1 

II  3670 

7 

46 

-01 

1 

II  2245 

162 

24 

-01 

1 

Ag  15  112 

18 

22 

-01 

2 

H  33  p210  55 

16 

22 

-01 

1 

II  8548 

2 

53 

-01 

1 

II  10223 

2 

56 

-01 

1 

H  25  p377 

38 

51 

-01 

1 

II  2369 

5 

29 

-01 

1 

II  6104 

1 

54 

-01 

1 

SEG  22  191 

56 

-01 

1 

III. 3  42 

7 

86 

-01 

1 

I  947 

20 

51 

-01 

1 

II  957 

47 

11 

-02 

2 

II  958 

90 

11 

-01 

1 

II  1014 

5 

11 

-01 

1 

II  2334 

11 

26 

-01 

2 

II  2334 

11 

26 

-01 

3 

II  2334 

11 

26 

■01 

1 

H  25  p377 

34 

51 

-01 

1 

II  1043 

105 

24 

-01 

1 

FdeD  III. 2  23 

25 

24 

■01 

2 

FdeD  III. 2  23 

9 

24 

-01 

1 

II  6041 

5 

53 

-01 

2 

II  6041 

5 

53 

-01 

1 

II  8406 

1 

53 

■01 

1 

SEG  10  86 

61 

11 

■01 

2 

I  71 

86 

11 

■01 

1 

H  S8  p402  16 

71 

■01 

1 

II  5518 

3 

58 

•01 

1 

II  1624 

77 

35 

01 

1 

II  75 

7 

11 

01 

2 

Ag  15  492 

97 

22 

01 

3 

II  1698 

6 

22 

01 

1 

II  2325 

91 

28 

01 

2 

II  2325 

208 

28 
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nun 

ref  no 

item 

303780-0-01 

1 

1 

303780-0-02 

1 

1 

303790-0-02 

1 

2 

303780-0-02 

1 

3 

303780-0-02 

1 

4 

303780-0-02 

1 

5 

303780-0-02 

1 

6 

303780-0-02 

1 

7 

303780-0-02 

1 

8 

303780-0-02 

1 

9 

303780-0-02 

1 

10 

303780-0-02 

1 

11 

303780-0-02 

1 

12 

303780-0-02 

1 

13 

303780-0-02 

1 

14 

303780-0-02 

1 

15 

303780-0-02 

1 

16 

303780-0-02 

1 

17 

303780-0-02 

1 

18 

303780-0-02 

1 

19 

303780-0-02 

1 

20 

303780-0-04 

1 

1 

303780-0-04 

1 

2 

303780-0-04 

1 

2 

303780-0-04 

1 

3 

303780-0-04 

1 

4 

303780-0-05 

1 

1 

303780-0-05 

1 

2 

303780-0-05 

1 

3 

303780-0-05 

1 

4 

303780-0-05 

3 

1 

303780-0-05 

3 

2 

303780-2-01 

1 

1 

303780-2-01 

1 

1 

303780-3-01 

1 

1 

303785-0-01 

1 

1 

303785-0-02 

1 

1 

303785-0-03 

1 

1 

303785-0-04 

1 

1 

303785-0-05 

1 

1 

303785-1-01 

1 

1 

TEXTS  RELATION 
text 

’Ep^v'/vios  A^§inn/lols. 

Kard  tA  Ancp6T<nMa  t?|s  *Ap(ou  ndyou  koI 

PouXt)$  tQ>v  >  -^jjv  <  Kol  Tou  A'ffjiou  ToO  ’A0T^yalwv  tAv 
dp^OKTa  T-^v  ToO  pociXAws  Av  SeapoSATais  dpx'^^  ifoi 
dp^ovTo  An6vupov  dpx'^v  xal  navT^yupiapxAiaavTa 
»cai  dywKoSe T+jaavTa  twk  peydXcjv  navoS'nvalwv  oYko- 
6ty  tepAa  nayay9|  >  HA  <  'EpAv  <  AA^innoy  flToXepalou 
"Eppeiov  tAv  />AjTopa  koI  auyypo^Aa  dp«T?|$  i^veica  ot  naiAtesl. 
(vacat ) 

AXk^  Kal  pOdoiat  ical  Ay  ^ouXaiai  KpartaTous 
&ydpo$  dyaKXelTow$  yetyoTo  KcKpontri, 

Cy  Ifya  icai  AA§innoy,  8$  taToptT^y  AaaSptiaas 
al(Ayo$  AoXix'^y  dTpeKAws  Jf^powyey 
Kal  Td  pAy  oAtAs  AaetAe,  rd  A'Ar  ^A^Xcoy  dyaXA^os 
eOpaxo  nayTol'qy  laxopl'ns  drponAy. 

^  pAyo  xXeiyAs  dy^p,  8s  yoO  dno  puploy  8ppa 
AxTclyas  np^t^iots  A|Apa6ey. 

4>A^‘n  pAy  nepl^wTos  dy*  'EXXdAa,  T+jy  6  yeayStis 
aTyos  Aex(nn<p  A&icey  A4>’  laropl-q. 

ToOyeica  6A  koI  naiAes  dydrXeiroy  yeyexi^pa 
pop^eyxa  X(6ou  6^ay  dpei^Apeyoi. 

lA  ae  IpyAxaxos  dy  [w/yo0l Axrjs  xwy  pelyd/Xcoyl  naya0T)yat  Iwy/ 

Kol  llepeAs  naya[y‘^)s/*EplAyy los  AA|[in/nos]  nxoXepa(o[u/ 

Kot  tlepeAs  nayaly^s/*EplAyyto$  AA§Iin/nosl  RxoXepaloCu/ 
"Eppleios  xA  dK  pt  o/ax6  1  Xi  oy  x^  nAXlei/xi^  niaya0T)yat6/I  os 
oicdl<^T)s  Koil  xA  8Ao/ls  T?|ls  0toO  dyAaxT^/[aey  1 .  ''  / 

*Aya0?^i  xAx'TH / 1 X  1  Ay  dp^ayxa  r^v  xoO  ^oo  [  i /XA  la>s  dpx*^^ 
Andyupoy/ [dp Ixoyxa,  xAy  Kpdxiaxoy/( (e ]pAo  nayay^i  <  RAnXioy 
'EpA[y/yi)oy  AA^innoy  nxoXepolo  [u/*'Ep]pe  loy  *  ot  naiAes 
'EpAyy  i  o  [  s/A  ]A^  i  nnos  koI  *Epeyy(a  'Eppco/ydic  xe  la  xAy  noxApo./ 

[ - Igt  (Kat  xlAy  Antdyupoy  dpxoyxa/xal  leplAa  nayayx^ 

HA  t'EpAyyioy  AA§in/noy  "Eplpeioy  ... 

=  text  303780-0-05  refl 
»  text  303780-0-05  refl 
=  text  303780-0-05  refl 
®  text  303780-0-05  refl 
/rupyaalapxoi/Z'EpAy  AA^innos  *'Epp/ 

/’Aywyo0Axai//AA§ innos  ’Ayxwyoelwy  Ant  Md[pK<p)/ 
/auaxpeppaxdpxai // ’EpA y  AA^innos  *'Epp/ 

/yowpdxos  'EpAyyios/AA§ innos/twith  relief  of  man  in  ship) 

=  text  303780-0-05  refl 


APPENDIX  B  page  5 


303786-2-01 

303786-2-01 

303790-0-01 

303796-1-01 

303810-1-01 

303816-0-01 

303820-0-01 

303826-0-01 

303830-0-01 

303836-0-01 

303840-0-01 

303846-0-01 

303846-0-01 

303846-0-02 

303846-0-02 

303860-0-01 

303856-1-01 

303866-1-01 

303860-0-01 

303866-0-01 

303876-1-01 

303876-1-01 

303880-0-01 

303886-0-01 

303890-1-01 

303900-1-01 

303900-1-01 

303906-1-01 

303906-1-01 

303910-0-01 

303910-0-01 

303916-0-01 

303920-0-01 


1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

2 

2 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

2 

1 

2 

1 

1 


TEXTS  RELATION  (Cont'd) 

1  yupyaa  lapxo  I  /  'Ep^y  flToXepoTos  "EpH 

2  /  'Ep4y  Ai^innos  *'Epja  / 

1  nX[h>6)cTs/Ai ^  innos  I - 1 

1  At  .  .  .  1 1  (  IG1ti$ 

1  '  AplpyTyjTos/Ac^  I  nno/I6ptos  • 

1 

1  '  Inno6<uyT[  (dos  ]/A4^  1$  PI - 1 

1  A4^is  Ae^  i»cpATous/’Epxi«6s 
1  Ae^ls 
1  A  [  e  ^  ]  i<|MiiyT)5 
1  Acx^o  1 (AlayrlOos) 

1  /t^i  Xapndidi  xOy  nallAlcoy  4ic  T?|$/Tip4ou  naXalartplas 

2  Ae|i<^y/  KaXXi<^you  0[llycTdo$ 

1  /  dKdpnioy  4k  rQ>v  lnn4wy  / 

2  Ae§i4>&y  KaXXi^ytou  OllyeiAos  ^X^s/ 

1  Ae  5  ^X^P  ^  ^  ^  ^ - ^ 

1  *Iep6yupos  RaXXTjyeOs  un4p  4auToO/Kal  yuyaixAs  Ae$oO$ 

2  Kol  toO/AoO  'lepcjyOpou  Kal  t?|5  Suyarpis/' lepoKXc  la^/ 

1  A4x<yoy 

1  A4^(*)y  NoupTjylxou  Tt - t§4yosl  Mey6yApou  Aipxoyro? 

1  Auow/AuaAy  Apou/  'EXeua  i  y  t  ou/6\jy6TT|p/A4  ^wyos/Kpwn  ( 6ou/ 

2  yvjy'f^ 

1  Aios/ATm-nTplou/BepeeCis . 

1  [A41pdas 

1  AepK^TT^s  father  of  41X40$ 

1  0n4p  AepK4Tou  E4^ttI(ou)  n§T)l$  1  Acpk4tou 

2  I4>+it(tio$)  IkoM  auyxpi-f^papxo i 

1  [A1«pk4tt|$  ( [4  1uX6<7 1 0$  )  father  of  I - 1 

1  AeplK4TTi$l  (4vX60io$)  father  of  t .  .  l^yrjs 
1  [A14pKeTo$ 

1  A4pKeT0$ 

1  tA14pKeT0$ 

1  A4pKeT0$ 
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COMMENT  RELATION 


nun 


item  comment 


303780-0-01 

303780-0-01 

303780-0-01 

303780-0-01 

303780-0-01 

303780-0-01 

303780-0-02 

303780-0-02 

303780-0-02 

303780-0-03 

303780-0-03 

303780-0-03 

303780-0-03 

303780-0-04 

303780-0-04 

303780-0-05 

303780-1-01 

303780-1-01 

303780-2-01 

303780-3-01 

303785-0-01 

303785-0-01 

303785-0-01 

303785-0-02 

303785-0-02 

303785-0-02 

303785-1-01 

303785-2-01 

303785-2-01 

303785-2-01 

303815-0-01 

303830-0-01 

303840-0-01 

303840-0-01 

303845-0-01 

303845-0-01 

303845-0-01 

303845-0-02 

303845-0-02 

303855-1-01 

303870-1-01 

303875-1-01 

303875-2-01 

303880-0-01 

303885-0-01 

303900-1-01 

303900-1-01 

303900-1-01 

303905-1-01 

303905-1-01 

303910-0-01 

303910-0-01 

303910-0-01 

303915-0-01 

303920-0-01 


1  Fname  DOHAIOZ  EPENNIOE  AEZinnOI  HTOAEMAIOY  EPMEIOZ; 

2  Refloc  in  antro  Apollinis;  Refmod  rupestral  insc, 

3  in  the  cave  of  Apollo;  Xref  II  3667  1  7  (father  honoured); 

4  Namemod  1;  Stem  goto  EYAHMOZ  ( great -great -grandf at her ) ; 

5  Fkin  nonAIOZ  EPENNIOZ  RTOAEMAIOZ  EPMEIOZ;  Date  Follet  p510; 

6  Kinmod  1;  Xref  AEph  1972  ppl33-172  (stemmata); 

1  Fid  syngrapheus,  rhetor,  archon  (various),  panegyrist, 

2  agonothetes  etc);  Textdate  after  270p  (see  F.  Millar); 

3  Check  "F.  Millar**  ref; 

1  Fid  cun  Atheniensibus,  quorum  dux  fuit,  Herulos  vicit; 

2  Fref  Hist  Aug  Gallien  XIII  8;  NB  No  arpaT-nyla  mentioned 

3  in  IG  II.2  3669  (textdate  after  370p);  Check  ref, 

4  text,  date  "F.  Millar"  ref; 

1  Fid  agonothetes,  hiereus  panages,  dedicator  of  the 

2  HANAOHNAIAOZ  ZKA^HZ  (cf.  II  2245); 

1  Fid  hiereus  panages  (inter  alia); 

1  Fkin  EPENNIOZ  RTOAEMAIOZ  EPMEIOZ;  Kinmod  2; 

2  Ftef  father  not  given,  but  cf  stemma  ap  II  3665; 

1  Fkin  EPENNIOZ  AEZIRROZ  AEIIRROY  EPMEIOZ  303785; 

1  Fkin  EPENNIA  EPMQNAKTEIA; 

1  Stem  goto  EPENNIOZ  AEIIRROZ  RTOAEMAIOY  EPMEIOZ  (father), 

2  (303780);  Fname  EPENNIOZ  AEIIRROZ  AEIIRROY  EPMEIOZ; 

3  Namemod  2 ;  Kinmod  1 ; 

1  Fid  gymnasiarch,  agonothetes  of  the  Antoneia  4n(  M6pK(p 

2  (-03  refl),  systremroatarch  (-04  refl)  (all  same  insc.); 

3  Date  from  FILE,  ref  has  262/ 3p,  see  H  S12  1  note3; 

1  Fkin  EPENNIA  EPMONAKTEIA; 

1  Fkin  EPENNIOZ  RTOAEMAIOZ  EPMEIOZ;  Kinmod  2; 

2  Link  for  RTOAEMAIOZ  as  brother  of  AEIIRROZ  (2) 

3  see  stemma  ap  IG  II. 2  3665  and  AEph  1972  pi 35; 

1  Fid  in  a  funerary  list; 

1  Refloc  Eleusis; 

1  Fid  klerouch  on  Lemnos  AtipkIw^  iy  MuplKl-nsl;  Idmod  Lemnos; 

2  Ref  cf  ATL  3  p291-293; 

1  Fid  victor  at  the  Theseion  games  of  the  torch-race  for 

2  paides;  Idmod  Theseia;  Archon  ANOEZTHPIOZ; 

3  Date  from  file,  refl  has  156/7a; 

4  Fid  victor  at  the  Theseion  games  of  the  akampion  of  the 

5  hippeis;  Archon  ♦AIAPIAZ;  Date  from  file,  ref  has  155/4a; 

1  Fid  in  catalogue  of  donors  for  a  theatre; 

1  Check  FdeD ; 

1  Kinx  AYZn  AYZANAPOY  EAEYZINIOY; 

1  KinPlace  EAEYZINIOZ; 

1  Place  BEPEEYZ,  an  pro  0EPOIAIOZ?  cf  Steph.  Byz.  BEPOIA; 

1  Date  see  ATL  3  p313  note  61;  Reftie  reH  =  ref 2; 

1  Xref  APF  p97;  Date  textdate,  not  date  of  id.  Death  pre- 

2  sumably  before  this  date;  Kin  name  much  restored; 

3  Fid  commemorated  post  mortem  as  trierarch; 

1  Date  from  file  corrected  date  for  refl  (refl  gives  378/7a); 

2  AltDate  c  403a,  -413,  -393,  ref 2;  Reftie  ref 2  =  ref 3; 

1  Classmod  catalogue  of  the  Dionysia  and  Lenaia; 

2  Idmod  Dionysia;  Idmod  Lenaia;  Fid  comic  actor,  victor 

3  -  at  the  Dionysia  (refl)  and  at  the  Lenaia  (ref2); 

1  Fid  killed  at  Tanagra;  Idmod  Tanagra; 

1  Fid  killed  at  Tanagra;  Idmod  Tanagra; 
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303780-0  AE-innOE  son  of  HTOAEMAIOI  EPMEIOE  (5) 

PA/alias:  EPENNIOI  code:  2  stat:  11 
01  archon  a  255/6p  (255  AD  to  256  AD) 

1  ref:  IG  II. 2  2931  line:  2  class:  41 
'Ep^y/vio$  Ai^inn/loJ?. 

C  Fnaroe  nOHAIOI  EPENNIOI  AEZinnOI  HTOAEMAIOY  EPMEIOE; 

Refloc  in  antro  Apollinis;  Refmod  rupestral  insc, 

in  the  cave  of  Apollo;  Xref  II  3667  1  7  (father  honoured); 

Namemod  1;  Stem  goto  EYAHMOE  ( great -great -grandf ather) ; 

F)cin  nORAIOE  EPENNIOI  RTOAEMAIOE  EPMEIOE;  Date  Follet  p510; 

Kinmod  1;  Xref  Archaiologi)ce  Ephemeris  1972  ppl33-172  (steraroata) 

02  syngrapheus  c  269/70p  (259  AD  to  280  AD) 

1  ref:  IG  II. 2  3669  line:  6  class:  41 

xard  tA  inep^Ti^a  'Aptov  ndyou  xal 

PouXt)$  Twy-  >  >|»v  <  ral  toC  toO  ’ASt^v’oIwv  tAv 

Ap^avra  toO  p<xoiX^u>$  Av  BeapoSirais  dp^'J^v  xal 

dp^avra  inwvupoy  dp)(^v  ral  navT^yup iapx‘h^ci»'Ta 

xal  Aywyo6e xhtJcivTa  twv  peydXojv  RayaS'nva I wv  oYxo- 
0e y  (ep^a  nayayri  >  R6  <  'Ep^v  <  Ai^innoy  RToXepalou 
"Eppeioy  tAv  ^4)Topa  xal  avvypo^a  dper^S  Kvexa  ol  natACesl. 

( vacat ) 

dXx^  xal  puSoiai  xal  iv  ^ouXaiai  xparlaTovs 
fiiy8pa$  dyaxXetTovs  yelyaro  Kexponlr), 

Qy  ffya  xal  A^^innoy,  8$  laroplTjy  ^aaOp^f^cras 
aluyos  AoXix^v'  irpex^w^  lf4>pauTey- 

xal  tAi  pAy  auTA$  iaeiOe,  xd  A*4x  p^pXo>y  dvaXA^as 
cOpaxo  nayxolx^y  loxoplx)?  dxpanAv. 

pAya  xXeiyAs  dyf^p ,  b$  you  dno  puploy  8ppa 
Axxelyas  np^§i®S  4§Apa6ey. 

4>4jpTi  pAy  nepl^xo?  dy’  'EXXdAa,  xijy  6  yeayO+is 
aTyos  Aexlw^V  AtAxey  A4>’  laxoplij. 
xoCyexa  6A  xal  naifies  dydxXeixoy  yeyexi^pa 
pop4>deyxa  Xl9ou  ©xjxay  dpeipApeyoi. 

C  Fid  syngrapheus,  rhetor,  archon  (various),  panegyrist, 
agonothetes  etc);  Textdate  after  270p  (see  F.  Millar); 

Chec)c  "F.  Millar”  ref; 

03  strategos?  267p  (267  AD  to  267  AD) 

1  ref:  SHA  Gall  13  8  line:  class:  92 

C  Fid  cum  Atheniensibus ,  quorum  dux  fuit,  Herulos  vicit; 

Fref  Hist  Aug  Gallien  XIII  8;  NB  No  axpaxxiyla  mentioned 
in  IG  II. 2  3669  (textdate  after  370p);  Chec)c  ref, 
text,  date  "F.  Millar"  ref; 

04  agonothetes  262/3  aut  266/7p  (262  AD  to  267  AD) 

1  ref:  IG  II. 2  3198  line:  5  class:  46 

16  aelpyAxaxos  dy  Iw/yoelAxxis  xwy  pelyd/Xwyl  RayaOx^yal  twy/ 
xal  llepeus  nayalyii^/'EplAyy los  AA§lin/no$l  RxoXepalolu/ 

"Eppleios  xA  dxplo/oxAlXioy  x^  nAXtei/xPjs  RlayaSxtyal A/los 
axdl4)Tis  xal  xA  KAo/ls  xiil$  eeoO  dyAoxV 3  •  ''  / 

ref:  IG  II. 2  3669  line:  6  class:  41 


2 
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C  Fid  agonothetes,  hiereus  panages,  dedicator  of  the 
HANAeHNAIAOE  ZKA^HE  (cf.  II  2245); 

05  priest  a  266/7p  (246  AD  to  267  AD) 

1  ref:  IG  II. 2  3670  line:  6  class:  46 

'AyaO^i  tux^i/It)6v  ttp§avTa  xijy  toO  ^gu7 [  i /X4  ]u>s 
4n(dKupov'/[8ip]XovTa,  t6k  k pAx  kttov/ C  t  e  lp4a  navayTi  <  n6nXioK 
'Ep4[v/vi]oy  Li^innov  nxoXepat  o  [u/*'Ep  Ipe  lov  *  o(  noTOes 
*Ep4vy  io(s/A)^{  innos  »foii  'EpevvCa  'Eppw/vAK xe  la  xiv  nax4pa./ 

2  ref:  IG  II. 2  3198  line:  5  class: 

3  ref:  IG  II. 2  3671  line:  2  class:  46 

(— Ig  (koI  x16v  jnlAyupov  fiipxovxa/Kal  lepl^a  naKoyri 
n6  I'Ep^vKioK  A^^in/noK  "EplpeioK  ... 

C  Fid  hiereus  panages  (inter  alia); 

303780-1  AEEinnOE  father  of  RTOAEMAIOE  EPMEIOE  (5) 

PA/alias:  EPENNIOE  code:  2  stat:  11 
01  patronymic  c  242/3  /  246/7p  (232  AD  to  257  AD) 

1  ref:  IG  II. 2  2245  line:  14  class:  24 
C  Fkin  EPENNIOE  RTOAEMAIOE  EPMEIOE;  Kinrood  2; 

Ref  father  not  given,  but  cf  steroma  ap  II  3665; 

303780-2  AEZIRROE  father  of  AEZIRROE  EPMEIOE  (5) 

PA/alias:  EPENNIOE  code:  2  stat:  11 
01  ******  c  233/4p  (223  AD  to  244  AD) 

1  ref:  IG  II. 2  3670  line:  6  class:  46 

*  text  303780-0-05  refl 

C  Fkin  EPENNIOE  AEZIRROE  AEZIRROY  EPMEIOE  303785; 

303780-3  AEZIRROE  father  of  EPMONAKTEIA  EPMEIOE  (5) 

PA/alias:  EPENNIOE  code:  2  stat:  11 
01  ******  c  233/4p  (223  AD  to  244  AD) 

1  ref:  IG  II. 2  3670  line:  7  class:  46 

=*  text  303780-0-05  refl 
C  Fkin  EPENNIA  EPMONAKTEIA; 

»  *  » 


303785-0  AEZIRROE  son  of  AEZIRROE  EPMEIOE  (5) 

PA/alias:  EPENNIOE  code:  2  stat:  11 
01  dedicant  a  266/7p  (246  AD  to  267  AD) 

1  ref:  IG  II. 2  3670  line:  7  class:  46 
=  text  303780-0-05  refl 

C  Stem  goto  EPENNIOE  AEZIRROE  RTOAEMAIOY  EPMEIOE  (father), 
(303780);  Fnaroe  EPENNIOE  AEZIRROE  AEZIRROY  EPMEIOE; 
Naraemod  2 ;  Kinmod  1 ; 


02  gymnasiarch  254/5p  (254  AD  to  255  AD) 

1  ref:  IG  II. 2  2245  line:  162  class:  24 
/PupKoaCapxo i//'Ep4v  A4§inno$ 

C  Fid  gymnasiarch,  agonothetes  of  the  Antoneia  M6pK<^ 
(-03  refl),  systreroroatarch  (-04  refl)  (all  same  insc.); 
Date  from  FILE,  ref  has  262/ 3p,  see  H  S12  1  note3; 
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03 

04 

05 

303785-1 

01 

303785-2 

01 


303790-0 

01 


303795-1 

01 


agonothetes  254/5p  (254  AD  to  255  AD) 

1  raf:  IG  II. 2  2245  lina:  177  claas:  24 

/*Aywvo0^Tai//A45 'AvTWKoelwv  4nl  M6[pK(^)/ 

sy St raroniat arches  254/5p  (254  AD  to  255  AD) 

1  ra£:  IG  II. 2  2245  line:  303  class:  24 

/a\jaTpenpaT6pxai//*Ep4v  A4§inno$  ’'Epp/ 

naumachos  254/5p  (254  AO  to  255  AD) 

1  ref:  IG  II. 2  2245  line:  477  class:  24 

/v’aupdxo;  'Ep^yvio^/A^^  inno9/(with  relief  of  man  in  ship) 

AEZinnor  brother  of  EPMQNAKTEIA  EPMEIOI  (5) 

PA/alias:  EPENNIOE  coda:  2  stat:  11 

. *  a  266/7p  (246  AD  to  267  AD) 

1  ref:  IG  II. 2  3670  line:  7  class:  46 
=  text  303780-0-05  refl 
C  Fkin  EPENNIA  EPMONAKTEIA; 

AEIirmOZ  brother  of  HTOAEMAIOZ  EPMEIOE  (5) 

PA/alias:  EPENNIOE  code:  2  stat:  11 

.  262/3  aut  266/7p  (262  AD  to  267  AD) 

1  ref:  IG  II. 2  2245  line:  162  class:  24 

yupvoa ( apxo I /  'Ep4v  nToXcpaTo$  "Epp 
/  'Epiv  A4§innos  "Epp  / 

C  Fkin  EPENNIOE  RTOAEMAIOE  EPMEIOE;  Kiniiiod  2; 

Lin)c  for  RTOAEMAIOE  as  brother  of  AEZIRROE  (2) 

see  stemina  ap  IG  II. 2  3665  and  Archaiologi)ce  Ephemaris  1972  pi 35 


«  « 


AEZIRROE  RAOeeVE  (2) 
code:  1  stat:  1 

councillor  Ilia  ( 300  BC  to  200  BC) 

1  ref:  Agora  15  112  line:  18  class:  22 

RXlo>e)eTs/A4|  innos  t - 1 

2  ref:  Hesperia  33  p210  55  line:  16  class:  22 


AEZIRROE  father  of  A. . .HIE  HPAKAEOTIE 
code:  1  stat:  71 
patronymic  Ip  (1  AD  to  100  AD) 

1  ref:  IG  II. 2  8548  line:  2  class:  53 
AI  .  .  .  Itils/Ae  I  Innow/'HparXe  IwIti? 


AEZIRROE  father  of  APIMNHETOE  EAMIOE 
code:  1  stat:  71 


303810-1 
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01 


303815-0 

01 


303820-0 

01 


303825-0 

01 


303830-0 

01 


303835-0 


patronymic  in  IVa  ( 400  BC  to  380  BC ) 

1  ref:  IG  II. 2  10223  line:  2  class:  56 
'AptiiVTpTos/Ael  (nno/Zdp  io$ . 


»  • 


AEIII 

code:  1  stat:  100 

casualty  465/4a?  (465  BC  to  464  BC) 

1  ref:  Hesperia  25  p377  line:  38  class:  51 

C  Fid  in  a  funerary  list; 


«  * 


AEZIZ  son  of  T-  mnoOONTIAOE  (8) 
code:  1  stat:  1 

in  catalogue  in  IVa  (400  BC  to  380  BC) 

1  ref:  IG  II. 2  2369  line:  5  class:  29 
'  InnoSidVTt  (do5  ]/A4§  i S  PC - ) 


AEZir  son  of  AEZIKPATHE  EPXIEYE  (2) 
PA/alias:  3238  code:  1  stat:  1 
epitaph  m  IVa  (360  BC  to  340  BC) 

1  ref:  IG  II. 2  6104  line:  1  class:  54 
Ae^ iKpdrous/’Epxie^s 


AEZIE  eHBAIA 

code:  1  stat:  -71 

epitaph  IVa/  pa  p  (400  BC  to  280  BC) 

1  ref:  SEG  22  191  line:  class:  56 

C  Refloc  Eleusis; 


»  « 


AEZIdANHE 

code:  1  stat:  100 
cursed  Ilia  (300  BC  to  200  BC) 

1  ref:  III. 3  42  line:  7  class:  86 
A  [  e  ^  }  1 4>dy  Tis 


01 
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303840-0 

01 


303845-0 

01 


02 


303850-0 

01 


303855-1 

01 

303855-2 

01 

303855-3 


AEZUIAOI  AIANTIAOE  (9) 

PA/alias:  3239  code:  1  stat:  1 
klerouch  p  n  Va  (450  BC  to  430  BC) 

1  ref:  IG  1.2  947  line:  20  class:  51 
Aexl<’n^iXos  (Alavrldos) 

C  Fid  klerouch  on  Lesmos  ^rpiV^fay  iy  hup(y[T)$];  Idstod  Lesnos 
Ref  cf  ATL  3  p291-293; 


«  «  * 


AEII^ON  son  of  KAAAI4ANHE  OINEIAOE  (6) 

PA/alias:  3240  code:  1  stat:  1 
victor  157/6a  (157  BC  to  156  BC) 

1  ref:  IG  II. 2  957  line:  47  class:  11 

/T9|i  XapndOi  rCtv  naltdluy  4k  naXalartplas 

Ae^i^v/  KaXXi^vov  Oltlyeido^  ^X[^l. 

C  Fid  victor  at  the  Theseion  games  of  the  torch-race  for 
paides;  Idmod  Theseia;  Archon  ANOEETHPIOI; 

Date  from  file,  refl  has  158/7a; 

victor  149/8a  (149  BC  to  148  BC) 

2  ref:  IG  II. 2  958  line:  90  class:  11 

/  ''  dKdpnioy  4k  tOv  tnn4fa)v*  / 

Ae^i^y  KoXXi^vlou  0]lveT6o$ 

C  Fid  victor  at  the  Theseion  games  of  the  akas^ion  of  the 
hippeis;  Archon  4AIAPIAI;  Date  from  file,  ref  has  155/4a; 


AEIIXAPIE  son  of  ♦!-  - 

PA/alias:  3241  code:  1  stat:  1 
epistates,  proedros  109/8a  (109  BC  to  108  BC) 

1  ref:  IG  II. 2  1014  line:  5  class:  11 
Ac^(Xopi5  ♦I  I - J 


*  » 


AEIO  wife  of  lEPONYMOE  HAAAHNEYE  (10) 

PA/alias:  3242  code:  1  stat:  -1 
in  catalogue  a  m  Ila  (170  BC  to  150  BC) 

1  ref:  IG  II. 2  2334  line:  11  class:  26 

'Iep<l>yupos  DoXXtivcOs  0n4p  4ovToO/Kal  yvyaiK6$  Ac|oGs 
Kol  ToO/OoO  *Iep<dvGpou  koI  OuyarpAs/ '  IcpoKXe  (05/ 

C  Fid  in  catalogue  of  donors  for  a  theatre; 

AEZn  mother  of  lEPONYMOE  RAAAHNEYE  (10) 

PA/alias:  3242  code:  1  stat:  -1 
•*•«#*  a  m  Ila  (170  BC  to  150  BC) 

2  ref:  IG  II. 2  2334  line:  11  class:  26 

AEZO  mother  of  lEPOKAEIA  RAAAHNEYE  (10) 

PA/alias:  3242  code:  1  stat:  -1 
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01 

303860-0 

01 


303065-0 

01 


303870-1 

01 

303870-2 

01 

303875-1 

01 

303875-2 

01 


****  a  n  Ila  (170  BC  to  150  BC) 

3  ra£:  IG  11.2  2334  lina:  11  class:  26 


«  «  « 


AEION 

code:  1  stat:  100 

casualty  465/4a?  (465  BC  to  464  BC) 

1  ref:  Hesperia  25  p377  line:  34  class:  51 
t^Xoov 


«  • 


AEIQN  son  of  NOYMHNIXOI  T- 
code:  1  stat:  71 
ephebe  39/8a  (39  BC  to  38  BC) 

1  ref:  IG  II. 2  1043  line:  105  class:  24 

Nowp'nvtxou  T( - Meydvfipou 


•  •  • 


AEZQN  father  of  AEZIOXOE 

PA/alias:  S  code:  1  stat:  100 
patronyiiic  c  156/7a  (168  BC  to  147  BC) 

1  ref:  Fouilles  de  Delphes  III  part  2  23  line:  25  class:  24 
C  Check  PdeD ; 

AEIQN  father  of  NIKANAPOI 

PA/alias:  S  code:  1  stat:  100 
patronymic  c  158/7a  (168  BC  to  147  BC) 

2  ref:  Fouilles  de  Delphes  III  part  2  23  line:  9  class:  24 


AEIQN  husband  of  AYIQ  KPOTIIAHI  (4) 

PA/alias:  3243  code:  1  stat:  1 
patronymic  la  (100  BC  to  1  BC) 

1  ref:  IG  II. 2  6041  line:  5  class:  53 

AuaA/Aua4v6pou/  *EXe  uo  i  y  ( ou/SuyAx'np/Ai  ^cay  0$  /Kpwn  ( Aou/ 
yuy4t 

C  Kinx  AYIQ  AYZANAPOY  EAEYIINIOY; 

AEZQN  son-in-law  of  AYEANAPOZ  EAEYEINIOE  (8) 

PA/alias:  3243  code:  1  stat:  1 
patronymic  la  (100  BC  to  1  BC) 

2  ref:  IG  II. 2  6041  line:  5  class:  53 

C  KinPlace  EAEYEINIOE; 
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303880-0 

01 


303885-0 

01 


303890-1 

01 


303895-1 

01 

303900-1 

01 


303905-1 


AEOI  son  of  AHMHTPIOI  BEPOIAIOI? 
code:  1  stat:  71 

epitaph  aet  Rom  (150  BC  to  300  AD) 

1  ref:  IG  II. 2  8406  line:  1  class:  53 
A4os/At|pt^tp  (ou/6e  pec  6$. 

C  Place  BEPEEYE,  an  pro  BEPOIAIOZ?  cf  Steph.  Byz.  BEPOIA; 


AEPAAE  MAKEAQN 

code:  1  stat:  71 
ruler  c  436a  (446  BC  to  426  BC) 

1  ref:  SEG  10  86  line:  61  class:  11 

(A4 ]p6a$ 

2  ref:  IG  1.2  71  line:  86  class:  11 

C  Date  see  ATL  3  p313  note  61;  Reftie  refl  ^  ref 2; 


AEPKETHE  father  of  ♦lAEAE 
code:  1  stat:  100 

patronymic  a  f  Via  (520  BC  to  500  BC) 

1  ref:  Hesperia  S8  p402  16  line:  class:  71 

AepK4TT)s  father  of  4iX4as 


AEPKETHE  father  of  ♦lATO 
PA/ alias:  3244  code:  1 
patronymic  IVa?  (400  BC  to  300  BC) 

1  ref:  IG  II. 2  5518  line:  3  class:  58 


AEPKETHE  father  of  EYREieHE  E^HTTIOE  (5) 

PA/alias:  D  code:  1  stat:  1 
trierarch  336/5-331/Oa  (336  BC  to  330  BC) 

1  ref:  IG  II. 2  1624  line:  77  class:  35 

0n4p  AepKirou  E^tt((ou)  ^10  )qc  [  ( Id's!  5  )  AepKirov 
E^t(tios)  [koII  <TvyTpi4)papxoi 

C  Xref  Davies,  Ath  Prop  Fam  p97;  Data  textdate,  not  date  of  id. 
Death  presumably  before  this  date;  Kin  name  much  restored; 

Fid  commemorated  post  mortem  as  trierarch; 


»  •  • 


AEPKETHE  father  of  -♦ANHE  ♦YAAEIOE 
PA/alias:  3245  code:  1  stat:  2 
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01  patronynic  c  401/0a  (411  BC  to  390  BC) 

1  ref:  IG  II. 2  75  line:  7  class:  11 

[AlcpK^T^  ( [4]uX6a  10$ )  father  of  [ - 1 

2  ref:  Agora  15  492  line:  97  class:  22 
Aeptx^T'ns]  (4uX6aio$)  father  of  I . . 

3  ref:  IG  II. 2  1698  line:  6  class:  22 

C  Date  from  file  corrected  date  for  refl  (refl  gives  378/7a) 
AltDate  c  403a,  -413,  -393,  re£2;  Ref  tie  ref  2  =»  ref  3; 


303910-0  AEPKETOE 

code:  1  stat:  100 

01  actor,  comic  in  Ilia  (3(X)  BC  to  280  BC) 

1  ref:  IG  II. 2  2325  line:  91  clast:  28 
(A]4pKeTos 

2  ref:  IG  II. 2  2325  line:  208  class:  28 

d4piCCTO$ 

C  Classmod  catalogue  of  the  Dionysia  and  Lenaia; 

Idmod  Dionysia;  Idmod  Lenaia;  Fid  comic  actor,  victor 
-  at  the  Dionysia  (refl)  and  at  the  Lenaia  (ref 2); 


303915-0  AEPKETOE  APPEIOE 

code:  1  stat:  71 

01  casualty  458a  (458  BC  to  458  BC) 

1  ref:  Agora  17  4  line:  22  class:  51 

(AlipKeros 

2  ref:  SEG  10  407  line:  40  class:  51 
C  Fid  killed  at  Tanagra;  Idmod  Tanagra; 


303920-0  AEPKETOE  APPEIOE 

code:  1  stat:  71 

01  casualty  458a  (458  BC  to  458  BC) 

1  ref:  Agora  17  4  line:  75  class:  51 

dipKCTOS 

2  ref:  SEG  10  407  line:  123  class:  51 
C  Fid  killed  at  Tamagra;  Idmod  Tanagra; 


303925-1  AEPKmnOE  father  of  .  .0 . E  KOeOKIAHE 

code:  1  stat:  2 

01  patronymic  la  (100  BC  to  1  BC) 

1  ref:  IG  II. 2  6473  line:  2 


class:  53 


